linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Vlastimil Babka <vbabka@suse.cz>
To: Pasha Tatashin <pasha.tatashin@soleen.com>
Cc: Christoph Lameter <cl@linux.com>,
	David Rientjes <rientjes@google.com>,
	Joonsoo Kim <iamjoonsoo.kim@lge.com>,
	Pekka Enberg <penberg@kernel.org>,
	Hyeonggon Yoo <42.hyeyoo@gmail.com>,
	Matthew Wilcox <willy@infradead.org>,
	Roman Gushchin <roman.gushchin@linux.dev>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	"linux-mm@kvack.org" <linux-mm@kvack.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Rustam Kovhaev <rkovhaev@gmail.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Josh Triplett <josh@joshtriplett.org>,
	Arnd Bergmann <arnd@arndb.de>,
	Russell King <linux@armlinux.org.uk>,
	Alexander Shiyan <shc_work@mail.ru>,
	Aaro Koskinen <aaro.koskinen@iki.fi>,
	Janusz Krzysztofik <jmkrzyszt@gmail.com>,
	Tony Lindgren <tony@atomide.com>,
	Yoshinori Sato <ysato@users.sourceforge.jp>,
	Rich Felker <dalias@libc.org>, Jonas Bonn <jonas@southpole.se>,
	Stefan Kristiansson <stefan.kristiansson@saunalahti.fi>,
	Stafford Horne <shorne@gmail.com>,
	"linux-arm-kernel@lists.infradead.org" 
	<linux-arm-kernel@lists.infradead.org>,
	"linux-olinux-omap@vger.kernel.orgmap"@vger.kernel.org,
	openrisc@lists.librecores.org, linux-riscv@lists.infradead.org,
	linux-sh@vger.kernel.org,
	Geert Uytterhoeven <geert@linux-m68k.org>,
	Conor.Dooley@microchip.com,
	Damien Le Moal <damien.lemoal@opensource.wdc.com>,
	Paul Cercueil <paul@crapouillou.net>
Subject: Re: Deprecating and removing SLOB
Date: Fri, 11 Nov 2022 11:33:30 +0100	[thread overview]
Message-ID: <c1caa5ce-eeaf-8038-2dea-051c98aade45@suse.cz> (raw)
In-Reply-To: <CA+CK2bD-uVGJ0=9uc7Lt5zwY+2PM2RTcfOhxEd65S7TvTrJULA@mail.gmail.com>

On 11/8/22 22:44, Pasha Tatashin wrote:
> On Tue, Nov 8, 2022 at 10:55 AM Vlastimil Babka <vbabka@suse.cz> wrote:
>>
>> Hi,
>>
>> as we all know, we currently have three slab allocators. As we discussed
>> at LPC [1], it is my hope that one of these allocators has a future, and
>> two of them do not.
>>
>> The unsurprising reasons include code maintenance burden, other features
>> compatible with only a subset of allocators (or more effort spent on the
>> features), blocking API improvements (more on that below), and my
>> inability to pronounce SLAB and SLUB in a properly distinguishable way,
>> without resorting to spelling out the letters.
>>
>> I think (but may be proven wrong) that SLOB is the easier target of the
>> two to be removed, so I'd like to focus on it first.
>>
>> I believe SLOB can be removed because:
>>
>> - AFAIK nobody really uses it? It strives for minimal memory footprint
>> by putting all objects together, which has its CPU performance costs
>> (locking, lack of percpu caching, searching for free space...). I'm not
>> aware of any "tiny linux" deployment that opts for this. For example,
>> OpenWRT seems to use SLUB and the devices these days have e.g. 128MB
>> RAM, not up to 16 MB anymore. I've heard anecdotes that the performance
>> SLOB impact is too much for those who tried. Googling for
>> "CONFIG_SLOB=y" yielded nothing useful.
> 
> I am all for removing SLOB.
> 
> There are some devices with configs where SLOB is enabled by default.
> Perhaps, the owners/maintainers of those devices/configs should be
> included into this thread:
> 
> tatashin@soleen:~/x/linux$ git grep SLOB=y
> arch/arm/configs/clps711x_defconfig:CONFIG_SLOB=y
> arch/arm/configs/collie_defconfig:CONFIG_SLOB=y
> arch/arm/configs/multi_v4t_defconfig:CONFIG_SLOB=y
> arch/arm/configs/omap1_defconfig:CONFIG_SLOB=y
> arch/arm/configs/pxa_defconfig:CONFIG_SLOB=y
> arch/arm/configs/tct_hammer_defconfig:CONFIG_SLOB=y
> arch/arm/configs/xcep_defconfig:CONFIG_SLOB=y
> arch/openrisc/configs/or1ksim_defconfig:CONFIG_SLOB=y
> arch/openrisc/configs/simple_smp_defconfig:CONFIG_SLOB=y
> arch/riscv/configs/nommu_k210_defconfig:CONFIG_SLOB=y
> arch/riscv/configs/nommu_k210_sdcard_defconfig:CONFIG_SLOB=y
> arch/riscv/configs/nommu_virt_defconfig:CONFIG_SLOB=y
> arch/sh/configs/rsk7201_defconfig:CONFIG_SLOB=y
> arch/sh/configs/rsk7203_defconfig:CONFIG_SLOB=y
> arch/sh/configs/se7206_defconfig:CONFIG_SLOB=y
> arch/sh/configs/shmin_defconfig:CONFIG_SLOB=y
> arch/sh/configs/shx3_defconfig:CONFIG_SLOB=y
> kernel/configs/tiny.config:CONFIG_SLOB=y

Turns out that since SLOB depends on EXPERT, many of those lack it so
running make defconfig ends up with SLUB anyway, unless I miss something.
Only a subset has both SLOB and EXPERT:

> git grep CONFIG_EXPERT `git grep -l "CONFIG_SLOB=y"`
arch/arm/configs/collie_defconfig:CONFIG_EXPERT=y
arch/arm/configs/omap1_defconfig:CONFIG_EXPERT=y
arch/arm/configs/tct_hammer_defconfig:CONFIG_EXPERT=y
arch/arm/configs/xcep_defconfig:CONFIG_EXPERT=y
arch/openrisc/configs/or1ksim_defconfig:CONFIG_EXPERT=y
arch/openrisc/configs/simple_smp_defconfig:CONFIG_EXPERT=y
arch/riscv/configs/nommu_virt_defconfig:CONFIG_EXPERT=y
arch/x86/configs/x86_64_defconfig:CONFIG_EXPERT=y

So how about the following for -next and 6.2? I did try depending on BROKEN
as suggested, but didn't find a way to override it by enabling CONFIG_BROKEN=y
without modifying a Kconfig file, so this seems more graceful to me?

----8<----
From 58028e06eee8a7fb8a11908b6941fae000660e4d Mon Sep 17 00:00:00 2001
From: Vlastimil Babka <vbabka@suse.cz>
Date: Fri, 11 Nov 2022 11:04:55 +0100
Subject: [PATCH] mm, slob: rename CONFIG_SLOB to CONFIG_SLOB_DEPRECATED

As explained in [1], we would like to remove SLOB if possible.

- There are no known users that need its somewhat lower memory footprint
  so much that they cannot handle SLUB instead.

- It is an extra maintenance burden, and a number of features are
  incompatible with it.

- It blocks the API improvement of allowing kfree() on objects allocated
  via kmem_cache_alloc().

As the first step, rename the CONFIG_SLOB option in the slab allocator
configuration choice to CONFIG_SLOB_DEPRECATED. Add CONFIG_SLOB
depending on CONFIG_SLOB_DEPRECATED as an internal option to avoid code
churn. This will cause existing .config files and defconfigs with
CONFIG_SLOB=y to silently switch to the default (and recommended
replacement) SLUB, while still allowing SLOB to be configured by anyone
that notices and needs it. But those should contact the slab maintainers
and linux-mm@kvack.org as explained in the updated help. With no valid
objections, the plan is to update the existing defconfigs to SLUB and
remove SLOB in a few cycles.

[1] https://lore.kernel.org/all/b35c3f82-f67b-2103-7d82-7a7ba7521439@suse.cz/

Signed-off-by: Vlastimil Babka <vbabka@suse.cz>
---
 mm/Kconfig | 15 +++++++++++++--
 1 file changed, 13 insertions(+), 2 deletions(-)

diff --git a/mm/Kconfig b/mm/Kconfig
index 57e1d8c5b505..27c0d13314be 100644
--- a/mm/Kconfig
+++ b/mm/Kconfig
@@ -219,17 +219,28 @@ config SLUB
 	   and has enhanced diagnostics. SLUB is the default choice for
 	   a slab allocator.
 
-config SLOB
+config SLOB_DEPRECATED
 	depends on EXPERT
-	bool "SLOB (Simple Allocator)"
+	bool "SLOB (Simple Allocator - DEPRECATED)"
 	depends on !PREEMPT_RT
 	help
+	   Deprecated and scheduled for removal in a few cycles. SLUB
+	   recommended as replacement. If you need SLOB to stay, please
+	   contact linux-mm@kvack.org and people listed in the SLAB
+	   ALLOCATOR section of MAINTAINERS file, and state your use
+	   case.
+
 	   SLOB replaces the stock allocator with a drastically simpler
 	   allocator. SLOB is generally more space efficient but
 	   does not perform as well on large systems.
 
 endchoice
 
+config SLOB
+	bool
+	default y
+	depends on SLOB_DEPRECATED
+
 config SLAB_MERGE_DEFAULT
 	bool "Allow slab caches to be merged"
 	default y
-- 
2.38.0


  parent reply	other threads:[~2022-11-11 10:39 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-08 15:55 Deprecating and removing SLOB Vlastimil Babka
2022-11-08 18:18 ` Christophe Leroy
2022-11-08 19:17   ` Andrew Morton
2022-11-08 18:46 ` Roman Gushchin
2022-11-08 20:13   ` Yosry Ahmed
2022-11-09  9:09     ` Vlastimil Babka
2022-11-08 21:44 ` Pasha Tatashin
2022-11-09  9:00   ` Vlastimil Babka
2022-11-09 15:50     ` Aaro Koskinen
2022-11-09 16:45       ` Geert Uytterhoeven
2022-11-09 17:45       ` Mike Rapoport
2022-11-09 21:16       ` Janusz Krzysztofik
2022-11-09 17:57   ` Conor.Dooley
2022-11-09 23:00     ` Damien Le Moal
2022-11-11 10:25       ` Vlastimil Babka
2022-11-12  1:40         ` Damien Le Moal
2022-11-11 10:33   ` Vlastimil Babka [this message]
2022-11-11 20:46     ` Conor Dooley
2022-11-12  1:40       ` Damien Le Moal
2022-11-14  1:55       ` Damien Le Moal
2022-11-14  5:48         ` Damien Le Moal
2022-11-14  9:36           ` Vlastimil Babka
2022-11-14 11:35             ` Damien Le Moal
2022-11-14 14:47               ` Hyeonggon Yoo
2022-11-15  4:24                 ` Damien Le Moal
2022-11-15  4:28                   ` Damien Le Moal
2022-11-16  7:57                     ` Matthew Wilcox
2022-11-16  8:02                       ` Damien Le Moal
2022-11-16 17:51                   ` Vlastimil Babka
2022-11-17  0:22                     ` Damien Le Moal
2022-11-21  4:30                     ` Damien Le Moal
2022-11-21 17:02                       ` Vlastimil Babka
2022-11-14 11:50             ` Hyeonggon Yoo
2022-11-09 20:56 Paul Cercueil
2022-11-09 21:39 ` Linus Torvalds
2022-11-09 23:48   ` Aaro Koskinen
2022-11-09 23:51     ` Aaro Koskinen
2022-11-10  4:40     ` Theodore Ts'o
2022-11-10  7:31       ` Vlastimil Babka
2022-11-10  7:54         ` Feng Tang
2022-11-10 16:20         ` Matthew Wilcox
2022-11-11  9:37           ` David Laight

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=c1caa5ce-eeaf-8038-2dea-051c98aade45@suse.cz \
    --to=vbabka@suse.cz \
    --cc="linux-olinux-omap@vger.kernel.orgmap"@vger.kernel.org \
    --cc=42.hyeyoo@gmail.com \
    --cc=Conor.Dooley@microchip.com \
    --cc=aaro.koskinen@iki.fi \
    --cc=akpm@linux-foundation.org \
    --cc=arnd@arndb.de \
    --cc=catalin.marinas@arm.com \
    --cc=cl@linux.com \
    --cc=dalias@libc.org \
    --cc=damien.lemoal@opensource.wdc.com \
    --cc=geert@linux-m68k.org \
    --cc=iamjoonsoo.kim@lge.com \
    --cc=jmkrzyszt@gmail.com \
    --cc=jonas@southpole.se \
    --cc=josh@joshtriplett.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux-riscv@lists.infradead.org \
    --cc=linux-sh@vger.kernel.org \
    --cc=linux@armlinux.org.uk \
    --cc=openrisc@lists.librecores.org \
    --cc=pasha.tatashin@soleen.com \
    --cc=paul@crapouillou.net \
    --cc=penberg@kernel.org \
    --cc=rientjes@google.com \
    --cc=rkovhaev@gmail.com \
    --cc=roman.gushchin@linux.dev \
    --cc=shc_work@mail.ru \
    --cc=shorne@gmail.com \
    --cc=stefan.kristiansson@saunalahti.fi \
    --cc=tony@atomide.com \
    --cc=torvalds@linux-foundation.org \
    --cc=willy@infradead.org \
    --cc=ysato@users.sourceforge.jp \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).