Re: Deprecating and removing SLOB

Re: Deprecating and removing SLOB

[Vlastimil Babka]

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

Great point, thanks. Ccing. First mail here:
https://lore.kernel.org/all/CA%2BCK2bD-uVGJ0%3D9uc7Lt5zwY%2B2PM2RTcfOhxEd65S7TvTrJULA@mail.gmail.com/



>>
>> - Last time we discussed it [2], it seemed SLUB memory requirements can
>> be brought very close to SLOB's if needed. Of course it can never have
>> as small footprint as SLOB due to separate kmem_caches, but the
>> difference is not that significant, unless somebody still tries to use
>> Linux on very tiny systems (goes back to the previous point).
>>
>> Besides the smaller maintenance burden, removing SLOB would allow us to
>> do a useful API improvement - the ability to use kfree() for both
>> objects allocated by kmalloc() and kmem_cache_alloc(). Currently the
>> latter has to be freed by kmem_cache_free(), passing a kmem_cache
>> pointer in addition to the object pointer. With SLUB and SLAB, it is
>> however possible to use kfree() instead, as the kmalloc caches and the
>> rest of kmem_caches are the same and kfree() can lookup the kmem_cache
>> from object pointer easily for any of those. XFS has apparently did that
>> for years without anyone noticing it's broken on SLOB [3], and
>> legitimizing and expanding this would help some use cases beside XFS
>> (IIRC Matthew mentioned rcu-based freeing for example).
>>
>> However for SLOB to support kfree() on all allocations, it would need to
>> store object size of allocated objects (which it currently does only for
>> kmalloc() objects, prepending a size header to the object), but for
>> kmem_cache_alloc() allocations as well. This has been attempted in the
>> thread [3] but it bloats the memory usage, especially on architectures
>> with large ARCH_KMALLOC_MINALIGN, where the prepended header basically
>> has to occupy the whole ARCH_KMALLOC_MINALIGN block to be DMA safe.
>> There are ongoing efforts to reduce this minalign, but the memory
>> footprint would still increase, going against the purpose of SLOB, so
>> again it would be easier if we could just remove it.
>>
>> So with this thread I'm interested in hearing arguments/use cases for
>> keeping SLOB. There might be obviously users of SLOB whom this
>> conversation will not reach, so I assume the eventual next step would be
>> to deprecate it in a way that those users are notified when building a
>> new kernel and can raise their voice then. Is there a good proven way
>> how to do that for a config option like this one?
>>
>> Thanks,
>> Vlastimil
>>
>> [1] https://lpc.events/event/16/contributions/1272/ - slides in the
>> slabs.pdf linked there
>> [2]
>> https://lore.kernel.org/all/20211017135708.GA8442@kvm.asia-northeast3-a.c.our-ratio-313919.internal/#t
>> [3]
>> https://lore.kernel.org/all/20210930044202.GP2361455@dread.disaster.area/
>>
>>
>>

Re: Deprecating and removing SLOB

[Aaro Koskinen]

Hi,

On Wed, Nov 09, 2022 at 10:00:25AM +0100, Vlastimil Babka wrote:
> > On Tue, Nov 8, 2022 at 10:55 AM Vlastimil Babka <vbabka@suse.cz> wrote:
> >> 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:

[...]

> > arch/arm/configs/omap1_defconfig:CONFIG_SLOB=y

I have been using SLUB on my OMAP1 boards with 32 MB RAM, because of
better debugging features and the memory footprint difference doesn't
really matter for my use cases. Looking at history why SLOB was added
there, it seems it came from 6cfce27c14aa ("omap1: Add omap1_defconfig")
when separate boards configs were merged, and SX1 board happened to have
SLOB in there. This board is nowadays only used in QEMU anyway.

There are OMAP1 boards with only 16 MB, but support for those boards
will be removed. So from OMAP1 side, I don't think there is any real
need for SLOB anymore.

A.

Re: Deprecating and removing SLOB

[Geert Uytterhoeven]

On Wed, Nov 9, 2022 at 4:53 PM Aaro Koskinen <aaro.koskinen@iki.fi> wrote:
> On Wed, Nov 09, 2022 at 10:00:25AM +0100, Vlastimil Babka wrote:
> > > On Tue, Nov 8, 2022 at 10:55 AM Vlastimil Babka <vbabka@suse.cz> wrote:
> > >> 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:
>
> [...]
>
> > > arch/arm/configs/omap1_defconfig:CONFIG_SLOB=y
>
> I have been using SLUB on my OMAP1 boards with 32 MB RAM, because of
> better debugging features and the memory footprint difference doesn't
> really matter for my use cases. Looking at history why SLOB was added
> there, it seems it came from 6cfce27c14aa ("omap1: Add omap1_defconfig")
> when separate boards configs were merged, and SX1 board happened to have
> SLOB in there. This board is nowadays only used in QEMU anyway.
>
> There are OMAP1 boards with only 16 MB, but support for those boards
> will be removed. So from OMAP1 side, I don't think there is any real
> need for SLOB anymore.

Interestingly, the m68k defconfigs use either SLAB, or the default (SLUB).
So the poor old m68k machines (many of which have less than 32 MiB)
seem to do fine without SLOB...

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: Deprecating and removing SLOB

[Mike Rapoport]

On Wed, Nov 09, 2022 at 05:50:08PM +0200, Aaro Koskinen wrote:
> Hi,
> 
> On Wed, Nov 09, 2022 at 10:00:25AM +0100, Vlastimil Babka wrote:
> > > On Tue, Nov 8, 2022 at 10:55 AM Vlastimil Babka <vbabka@suse.cz> wrote:
> > >> 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:
> 
> [...]
> 
> > > arch/arm/configs/omap1_defconfig:CONFIG_SLOB=y
> 
> I have been using SLUB on my OMAP1 boards with 32 MB RAM, because of
> better debugging features and the memory footprint difference doesn't
> really matter for my use cases. Looking at history why SLOB was added
> there, it seems it came from 6cfce27c14aa ("omap1: Add omap1_defconfig")
> when separate boards configs were merged, and SX1 board happened to have
> SLOB in there. This board is nowadays only used in QEMU anyway.

Looks like the same happened with arch/arm/configs/pxa_defconfig. XCEP
board had SLOB in its defconfig and when common pxa_defconfig was created
it apparently used it.
Looks like the board has 64M of RAM, so dropping CONFIG_SLOB=y from
arch/arm/configs/pxa_defconfig and arch/arm/configs/xcep_defconfig seems
very reasonable.

-- 
Sincerely yours,
Mike.

Re: Deprecating and removing SLOB

[Janusz Krzysztofik]

On Wednesday, 9 November 2022 16:50:08 CET Aaro Koskinen wrote:
> Hi,
>
> On Wed, Nov 09, 2022 at 10:00:25AM +0100, Vlastimil Babka wrote:
> > > On Tue, Nov 8, 2022 at 10:55 AM Vlastimil Babka <vbabka@suse.cz> wrote:
> > >> 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:
>
> [...]
>
> > > arch/arm/configs/omap1_defconfig:CONFIG_SLOB=y
>
> I have been using SLUB on my OMAP1 boards with 32 MB RAM, because of
> better debugging features and the memory footprint difference doesn't
> really matter for my use cases. Looking at history why SLOB was added
> there, it seems it came from 6cfce27c14aa ("omap1: Add omap1_defconfig")
> when separate boards configs were merged, and SX1 board happened to have
> SLOB in there. This board is nowadays only used in QEMU anyway.
>
> There are OMAP1 boards with only 16 MB, but support for those boards
> will be removed. So from OMAP1 side, I don't think there is any real
> need for SLOB anymore.

Moreover, I always had issues with availability of socket buffers during USB
device setup when trying to use SLOB on Amstrad Delta based on OMAP1510,
the least powerful OMAP1.  Then, +1 for SLOB removal.

Thanks,
Janusz

Re: Deprecating and removing SLOB

[Vlastimil Babka]

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

Re: Deprecating and removing SLOB

[Conor Dooley]

On Fri, Nov 11, 2022 at 11:33:30AM +0100, Vlastimil Babka wrote:
> 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/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

> 
> 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/riscv/configs/nommu_virt_defconfig:CONFIG_EXPERT=y

I suppose there's not really a concern with the virt defconfig, but I
did check the output of `make nommu_k210_defconfig" and despite not
having expert it seems to end up CONFIG_SLOB=y in the generated .config.

I do have a board with a k210 so I checked with s/SLOB/SLUB and it still
boots etc, but I have no workloads or w/e to run on it.

Re: Deprecating and removing SLOB

[Damien Le Moal]

On 11/12/22 05:46, Conor Dooley wrote:
> On Fri, Nov 11, 2022 at 11:33:30AM +0100, Vlastimil Babka wrote:
>> 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/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
> 
>>
>> 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/riscv/configs/nommu_virt_defconfig:CONFIG_EXPERT=y
> 
> I suppose there's not really a concern with the virt defconfig, but I
> did check the output of `make nommu_k210_defconfig" and despite not
> having expert it seems to end up CONFIG_SLOB=y in the generated .config.
> 
> I do have a board with a k210 so I checked with s/SLOB/SLUB and it still
> boots etc, but I have no workloads or w/e to run on it.

I will try with SLUB over the weekend.

-- 
Damien Le Moal
Western Digital Research

Re: Deprecating and removing SLOB

[Damien Le Moal]

On 11/12/22 05:46, Conor Dooley wrote:
> On Fri, Nov 11, 2022 at 11:33:30AM +0100, Vlastimil Babka wrote:
>> 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/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
> 
>>
>> 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/riscv/configs/nommu_virt_defconfig:CONFIG_EXPERT=y
> 
> I suppose there's not really a concern with the virt defconfig, but I
> did check the output of `make nommu_k210_defconfig" and despite not
> having expert it seems to end up CONFIG_SLOB=y in the generated .config.
> 
> I do have a board with a k210 so I checked with s/SLOB/SLUB and it still
> boots etc, but I have no workloads or w/e to run on it.

I sent a patch to change the k210 defconfig to using SLUB. However...

The current default config using SLOB gives about 630 free memory pages
after boot (cat /proc/vmstat). Switching to SLUB, this is down to about
400 free memory pages (CONFIG_SLUB_CPU_PARTIAL is off).

This is with a buildroot kernel 5.19 build including a shell and sd-card
boot. With SLUB, I get clean boots and a shell prompt as expected. But I
definitely see more errors with shell commands failing due to allocation
failures for the shell process fork. So as far as the K210 is concerned,
switching to SLUB is not ideal.

I would not want to hold on kernel mm improvements because of this toy
k210 though, so I am not going to prevent SLOB deprecation. I just wish
SLUB itself used less memory :)


-- 
Damien Le Moal
Western Digital Research

Re: Deprecating and removing SLOB

[Damien Le Moal]

On 11/14/22 10:55, Damien Le Moal wrote:
> On 11/12/22 05:46, Conor Dooley wrote:
>> On Fri, Nov 11, 2022 at 11:33:30AM +0100, Vlastimil Babka wrote:
>>> 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/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
>>
>>>
>>> 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/riscv/configs/nommu_virt_defconfig:CONFIG_EXPERT=y
>>
>> I suppose there's not really a concern with the virt defconfig, but I
>> did check the output of `make nommu_k210_defconfig" and despite not
>> having expert it seems to end up CONFIG_SLOB=y in the generated .config.
>>
>> I do have a board with a k210 so I checked with s/SLOB/SLUB and it still
>> boots etc, but I have no workloads or w/e to run on it.
> 
> I sent a patch to change the k210 defconfig to using SLUB. However...
> 
> The current default config using SLOB gives about 630 free memory pages
> after boot (cat /proc/vmstat). Switching to SLUB, this is down to about
> 400 free memory pages (CONFIG_SLUB_CPU_PARTIAL is off).
> 
> This is with a buildroot kernel 5.19 build including a shell and sd-card
> boot. With SLUB, I get clean boots and a shell prompt as expected. But I
> definitely see more errors with shell commands failing due to allocation
> failures for the shell process fork. So as far as the K210 is concerned,
> switching to SLUB is not ideal.
> 
> I would not want to hold on kernel mm improvements because of this toy
> k210 though, so I am not going to prevent SLOB deprecation. I just wish
> SLUB itself used less memory :)

Did further tests with kernel 6.0.1:
* SLOB: 630 free pages after boot, shell working (occasional shell fork
failure happen though)
* SLAB: getting memory allocation for order 7 failures on boot already
(init process). Shell barely working (high frequency of shell command fork
failures)
* SLUB: getting memory allocation for order 7 failures on boot. I do get a
shell prompt but cannot run any shell command that involves forking a new
process.

So if we want to keep the k210 support functional with a shell, we need
slob. If we reduce that board support to only one application started as
the init process, then I guess anything is OK.

-- 
Damien Le Moal
Western Digital Research

Re: Deprecating and removing SLOB

[Vlastimil Babka]

On 11/14/22 06:48, Damien Le Moal wrote:
> On 11/14/22 10:55, Damien Le Moal wrote:
>> On 11/12/22 05:46, Conor Dooley wrote:
>>> On Fri, Nov 11, 2022 at 11:33:30AM +0100, Vlastimil Babka wrote:
>>>> 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/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
>>>
>>>>
>>>> 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/riscv/configs/nommu_virt_defconfig:CONFIG_EXPERT=y
>>>
>>> I suppose there's not really a concern with the virt defconfig, but I
>>> did check the output of `make nommu_k210_defconfig" and despite not
>>> having expert it seems to end up CONFIG_SLOB=y in the generated .config.
>>>
>>> I do have a board with a k210 so I checked with s/SLOB/SLUB and it still
>>> boots etc, but I have no workloads or w/e to run on it.
>> 
>> I sent a patch to change the k210 defconfig to using SLUB. However...

Thanks!

>> The current default config using SLOB gives about 630 free memory pages
>> after boot (cat /proc/vmstat). Switching to SLUB, this is down to about
>> 400 free memory pages (CONFIG_SLUB_CPU_PARTIAL is off).

Thanks for the testing! How much RAM does the system have btw? I found 8MB
somewhere, is that correct?
So 230 pages that's a ~920 kB difference. Last time we saw less  dramatic
difference [1]. But that was looking at Slab pages, not free pages. The
extra overhead could be also in percpu allocations, code etc.

>> This is with a buildroot kernel 5.19 build including a shell and sd-card
>> boot. With SLUB, I get clean boots and a shell prompt as expected. But I
>> definitely see more errors with shell commands failing due to allocation
>> failures for the shell process fork. So as far as the K210 is concerned,
>> switching to SLUB is not ideal.
>> 
>> I would not want to hold on kernel mm improvements because of this toy
>> k210 though, so I am not going to prevent SLOB deprecation. I just wish
>> SLUB itself used less memory :)
> 
> Did further tests with kernel 6.0.1:
> * SLOB: 630 free pages after boot, shell working (occasional shell fork
> failure happen though)
> * SLAB: getting memory allocation for order 7 failures on boot already
> (init process). Shell barely working (high frequency of shell command fork
> failures)
> * SLUB: getting memory allocation for order 7 failures on boot. I do get a
> shell prompt but cannot run any shell command that involves forking a new
> process.
> 
> So if we want to keep the k210 support functional with a shell, we need
> slob. If we reduce that board support to only one application started as
> the init process, then I guess anything is OK.

In [1] it was possible to save some more memory with more tuning. Some of
that required boot parameters and other code changes. In another reply [2] I
considered adding something like SLUB_TINY to take care of all that, so
looks like it would make sense to proceed with that.

[1]
https://lore.kernel.org/all/Yg9xSWEaTZLA+hYt@ip-172-31-19-208.ap-northeast-1.compute.internal/
[2] https://lore.kernel.org/all/eebc9dc8-6a45-c099-61da-230d06cb3157@suse.cz/

Re: Deprecating and removing SLOB

[Damien Le Moal]

On 11/14/22 18:36, Vlastimil Babka wrote:
> On 11/14/22 06:48, Damien Le Moal wrote:
>> On 11/14/22 10:55, Damien Le Moal wrote:
>>> On 11/12/22 05:46, Conor Dooley wrote:
>>>> On Fri, Nov 11, 2022 at 11:33:30AM +0100, Vlastimil Babka wrote:
>>>>> 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/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
>>>>
>>>>>
>>>>> 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/riscv/configs/nommu_virt_defconfig:CONFIG_EXPERT=y
>>>>
>>>> I suppose there's not really a concern with the virt defconfig, but I
>>>> did check the output of `make nommu_k210_defconfig" and despite not
>>>> having expert it seems to end up CONFIG_SLOB=y in the generated .config.
>>>>
>>>> I do have a board with a k210 so I checked with s/SLOB/SLUB and it still
>>>> boots etc, but I have no workloads or w/e to run on it.
>>>
>>> I sent a patch to change the k210 defconfig to using SLUB. However...
> 
> Thanks!
> 
>>> The current default config using SLOB gives about 630 free memory pages
>>> after boot (cat /proc/vmstat). Switching to SLUB, this is down to about
>>> 400 free memory pages (CONFIG_SLUB_CPU_PARTIAL is off).
> 
> Thanks for the testing! How much RAM does the system have btw? I found 8MB
> somewhere, is that correct?

Yep, 8MB, that's it.

> So 230 pages that's a ~920 kB difference. Last time we saw less  dramatic
> difference [1]. But that was looking at Slab pages, not free pages. The
> extra overhead could be also in percpu allocations, code etc.
> 
>>> This is with a buildroot kernel 5.19 build including a shell and sd-card
>>> boot. With SLUB, I get clean boots and a shell prompt as expected. But I
>>> definitely see more errors with shell commands failing due to allocation
>>> failures for the shell process fork. So as far as the K210 is concerned,
>>> switching to SLUB is not ideal.
>>>
>>> I would not want to hold on kernel mm improvements because of this toy
>>> k210 though, so I am not going to prevent SLOB deprecation. I just wish
>>> SLUB itself used less memory :)
>>
>> Did further tests with kernel 6.0.1:
>> * SLOB: 630 free pages after boot, shell working (occasional shell fork
>> failure happen though)
>> * SLAB: getting memory allocation for order 7 failures on boot already
>> (init process). Shell barely working (high frequency of shell command fork
>> failures)

I forgot to add here that the system was down to about 500 free pages
after boot (again from the shell with "cat /proc/vmstat").

>> * SLUB: getting memory allocation for order 7 failures on boot. I do get a
>> shell prompt but cannot run any shell command that involves forking a new
>> process.

For both slab and slub, I had cpu partial off, debug off and slab merge
on, as I suspected that would lead to less memory overhead.
I suspected memory fragmentation may be an issue but doing

echo 3 > /proc/sys/vm/drop_caches

before trying a shell command did not help much at all (it usually does on
that board with SLOB). Note that this is all with buildroot, so this echo
& redirect always works as it does not cause a shell fork.

>>
>> So if we want to keep the k210 support functional with a shell, we need
>> slob. If we reduce that board support to only one application started as
>> the init process, then I guess anything is OK.
> 
> In [1] it was possible to save some more memory with more tuning. Some of
> that required boot parameters and other code changes. In another reply [2] I
> considered adding something like SLUB_TINY to take care of all that, so
> looks like it would make sense to proceed with that.

If you want me to test something, let me know.

> 
> [1]
> https://lore.kernel.org/all/Yg9xSWEaTZLA+hYt@ip-172-31-19-208.ap-northeast-1.compute.internal/
> [2] https://lore.kernel.org/all/eebc9dc8-6a45-c099-61da-230d06cb3157@suse.cz/

-- 
Damien Le Moal
Western Digital Research

Re: Deprecating and removing SLOB

[Hyeonggon Yoo]

On Mon, Nov 14, 2022 at 08:35:31PM +0900, Damien Le Moal wrote:
> On 11/14/22 18:36, Vlastimil Babka wrote:
> > On 11/14/22 06:48, Damien Le Moal wrote:
> >> On 11/14/22 10:55, Damien Le Moal wrote:
> >>> On 11/12/22 05:46, Conor Dooley wrote:
> >>>> On Fri, Nov 11, 2022 at 11:33:30AM +0100, Vlastimil Babka wrote:
> >>>>> 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/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
> >>>>
> >>>>>
> >>>>> 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/riscv/configs/nommu_virt_defconfig:CONFIG_EXPERT=y
> >>>>
> >>>> I suppose there's not really a concern with the virt defconfig, but I
> >>>> did check the output of `make nommu_k210_defconfig" and despite not
> >>>> having expert it seems to end up CONFIG_SLOB=y in the generated .config.
> >>>>
> >>>> I do have a board with a k210 so I checked with s/SLOB/SLUB and it still
> >>>> boots etc, but I have no workloads or w/e to run on it.
> >>>
> >>> I sent a patch to change the k210 defconfig to using SLUB. However...
> > 
> > Thanks!
> > 
> >>> The current default config using SLOB gives about 630 free memory pages
> >>> after boot (cat /proc/vmstat). Switching to SLUB, this is down to about
> >>> 400 free memory pages (CONFIG_SLUB_CPU_PARTIAL is off).
> > 
> > Thanks for the testing! How much RAM does the system have btw? I found 8MB
> > somewhere, is that correct?
> 
> Yep, 8MB, that's it.
> 
> > So 230 pages that's a ~920 kB difference. Last time we saw less  dramatic
> > difference [1]. But that was looking at Slab pages, not free pages. The
> > extra overhead could be also in percpu allocations, code etc.
> > 
> >>> This is with a buildroot kernel 5.19 build including a shell and sd-card
> >>> boot. With SLUB, I get clean boots and a shell prompt as expected. But I
> >>> definitely see more errors with shell commands failing due to allocation
> >>> failures for the shell process fork. So as far as the K210 is concerned,
> >>> switching to SLUB is not ideal.
> >>>
> >>> I would not want to hold on kernel mm improvements because of this toy
> >>> k210 though, so I am not going to prevent SLOB deprecation. I just wish
> >>> SLUB itself used less memory :)
> >>
> >> Did further tests with kernel 6.0.1:
> >> * SLOB: 630 free pages after boot, shell working (occasional shell fork
> >> failure happen though)
> >> * SLAB: getting memory allocation for order 7 failures on boot already
> >> (init process). Shell barely working (high frequency of shell command fork
> >> failures)
> 
> I forgot to add here that the system was down to about 500 free pages
> after boot (again from the shell with "cat /proc/vmstat").
> 
> >> * SLUB: getting memory allocation for order 7 failures on boot. I do get a
> >> shell prompt but cannot run any shell command that involves forking a new
> >> process.
> 
> For both slab and slub, I had cpu partial off, debug off and slab merge
> on, as I suspected that would lead to less memory overhead.
> I suspected memory fragmentation may be an issue but doing
> 
> echo 3 > /proc/sys/vm/drop_caches
> 
> before trying a shell command did not help much at all (it usually does on
> that board with SLOB). Note that this is all with buildroot, so this echo
> & redirect always works as it does not cause a shell fork.
> 
> >>
> >> So if we want to keep the k210 support functional with a shell, we need
> >> slob. If we reduce that board support to only one application started as
> >> the init process, then I guess anything is OK.
> > 
> > In [1] it was possible to save some more memory with more tuning. Some of
> > that required boot parameters and other code changes. In another reply [2] I
> > considered adding something like SLUB_TINY to take care of all that, so
> > looks like it would make sense to proceed with that.
> 
> If you want me to test something, let me know.

Would you try this please?

diff --git a/mm/slub.c b/mm/slub.c
index a24b71041b26..1c36c4b9aaa0 100644
--- a/mm/slub.c
+++ b/mm/slub.c
@@ -4367,9 +4367,7 @@ static int kmem_cache_open(struct kmem_cache *s, slab_flags_t flags)
 	 * The larger the object size is, the more slabs we want on the partial
 	 * list to avoid pounding the page allocator excessively.
 	 */
-	s->min_partial = min_t(unsigned long, MAX_PARTIAL, ilog2(s->size) / 2);
-	s->min_partial = max_t(unsigned long, MIN_PARTIAL, s->min_partial);
-
+	s->min_partial = 0;
 	set_cpu_partial(s);
 
 #ifdef CONFIG_NUMA


and booting with and without boot parameter slub_max_order=0?

Thanks,
Hyeonggon

> 
> > 
> > [1]
> > https://lore.kernel.org/all/Yg9xSWEaTZLA+hYt@ip-172-31-19-208.ap-northeast-1.compute.internal/
> > [2] https://lore.kernel.org/all/eebc9dc8-6a45-c099-61da-230d06cb3157@suse.cz/
> 
> -- 
> Damien Le Moal
> Western Digital Research

Re: Deprecating and removing SLOB

[Damien Le Moal]

On 11/14/22 23:47, Hyeonggon Yoo wrote:
> On Mon, Nov 14, 2022 at 08:35:31PM +0900, Damien Le Moal wrote:
>> On 11/14/22 18:36, Vlastimil Babka wrote:
>>> On 11/14/22 06:48, Damien Le Moal wrote:
>>>> On 11/14/22 10:55, Damien Le Moal wrote:
>>>>> On 11/12/22 05:46, Conor Dooley wrote:
>>>>>> On Fri, Nov 11, 2022 at 11:33:30AM +0100, Vlastimil Babka wrote:
>>>>>>> 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/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
>>>>>>
>>>>>>>
>>>>>>> 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/riscv/configs/nommu_virt_defconfig:CONFIG_EXPERT=y
>>>>>>
>>>>>> I suppose there's not really a concern with the virt defconfig, but I
>>>>>> did check the output of `make nommu_k210_defconfig" and despite not
>>>>>> having expert it seems to end up CONFIG_SLOB=y in the generated .config.
>>>>>>
>>>>>> I do have a board with a k210 so I checked with s/SLOB/SLUB and it still
>>>>>> boots etc, but I have no workloads or w/e to run on it.
>>>>>
>>>>> I sent a patch to change the k210 defconfig to using SLUB. However...
>>>
>>> Thanks!
>>>
>>>>> The current default config using SLOB gives about 630 free memory pages
>>>>> after boot (cat /proc/vmstat). Switching to SLUB, this is down to about
>>>>> 400 free memory pages (CONFIG_SLUB_CPU_PARTIAL is off).
>>>
>>> Thanks for the testing! How much RAM does the system have btw? I found 8MB
>>> somewhere, is that correct?
>>
>> Yep, 8MB, that's it.
>>
>>> So 230 pages that's a ~920 kB difference. Last time we saw less  dramatic
>>> difference [1]. But that was looking at Slab pages, not free pages. The
>>> extra overhead could be also in percpu allocations, code etc.
>>>
>>>>> This is with a buildroot kernel 5.19 build including a shell and sd-card
>>>>> boot. With SLUB, I get clean boots and a shell prompt as expected. But I
>>>>> definitely see more errors with shell commands failing due to allocation
>>>>> failures for the shell process fork. So as far as the K210 is concerned,
>>>>> switching to SLUB is not ideal.
>>>>>
>>>>> I would not want to hold on kernel mm improvements because of this toy
>>>>> k210 though, so I am not going to prevent SLOB deprecation. I just wish
>>>>> SLUB itself used less memory :)
>>>>
>>>> Did further tests with kernel 6.0.1:
>>>> * SLOB: 630 free pages after boot, shell working (occasional shell fork
>>>> failure happen though)
>>>> * SLAB: getting memory allocation for order 7 failures on boot already
>>>> (init process). Shell barely working (high frequency of shell command fork
>>>> failures)
>>
>> I forgot to add here that the system was down to about 500 free pages
>> after boot (again from the shell with "cat /proc/vmstat").
>>
>>>> * SLUB: getting memory allocation for order 7 failures on boot. I do get a
>>>> shell prompt but cannot run any shell command that involves forking a new
>>>> process.
>>
>> For both slab and slub, I had cpu partial off, debug off and slab merge
>> on, as I suspected that would lead to less memory overhead.
>> I suspected memory fragmentation may be an issue but doing
>>
>> echo 3 > /proc/sys/vm/drop_caches
>>
>> before trying a shell command did not help much at all (it usually does on
>> that board with SLOB). Note that this is all with buildroot, so this echo
>> & redirect always works as it does not cause a shell fork.
>>
>>>>
>>>> So if we want to keep the k210 support functional with a shell, we need
>>>> slob. If we reduce that board support to only one application started as
>>>> the init process, then I guess anything is OK.
>>>
>>> In [1] it was possible to save some more memory with more tuning. Some of
>>> that required boot parameters and other code changes. In another reply [2] I
>>> considered adding something like SLUB_TINY to take care of all that, so
>>> looks like it would make sense to proceed with that.
>>
>> If you want me to test something, let me know.
> 
> Would you try this please?
> 
> diff --git a/mm/slub.c b/mm/slub.c
> index a24b71041b26..1c36c4b9aaa0 100644
> --- a/mm/slub.c
> +++ b/mm/slub.c
> @@ -4367,9 +4367,7 @@ static int kmem_cache_open(struct kmem_cache *s, slab_flags_t flags)
>  	 * The larger the object size is, the more slabs we want on the partial
>  	 * list to avoid pounding the page allocator excessively.
>  	 */
> -	s->min_partial = min_t(unsigned long, MAX_PARTIAL, ilog2(s->size) / 2);
> -	s->min_partial = max_t(unsigned long, MIN_PARTIAL, s->min_partial);
> -
> +	s->min_partial = 0;
>  	set_cpu_partial(s);
>  
>  #ifdef CONFIG_NUMA
> 
> 
> and booting with and without boot parameter slub_max_order=0?

Test notes: I used Linus 6.1-rc5 as the base. That is the only thing I
changed in buildroot default config for the sipeed maix bit card, booting
with SD card. The test is: booting and run "cat /proc/vmstat" and register
the nr_free_pages value. I repeated the boot + cat 3 to 4 times for each case.

Here are the results:

6.1-rc5, SLOB:
    - 623 free pages
    - 629 free pages
    - 629 free pages
6.1-rc5, SLUB:
    - 448 free pages
    - 448 free pages
    - 429 free pages
6.1-rc5, SLUB + slub_max_order=0:
    - Init error, shell prompt but no shell command working
    - Init error, no shell prompt
    - 508 free pages
    - Init error, shell prompt but no shell command working
6.1-rc5, SLUB + patch:
    - Init error, shell prompt but no shell command working
    - 433 free pages
    - 448 free pages
    - 423 free pages
6.1-rc5, SLUB + slub_max_order=0 + patch:
    - Init error, no shell prompt
    - Init error, shell prompt, 499 free pages
    - Init error, shell prompt but no shell command working
    - Init error, no shell prompt

No changes for SLOB results, expected.

For default SLUB, I did get all clean boots this time and could run the
cat command. But I do see shell fork failures if I keep running commands.

For SLUB + slub_max_order=0, I only got one clean boot with 508 free
pages. Remaining runs failed to give a shell prompt or allow running cat
command. For the clean boot, I do see higher number of free pages.

SLUB with the patch was nearly identical to SLUB without the patch.

And SLUB+patch+slub_max_order=0 gave again a lot of errors/bad boot. I
could run the cat command only once, giving 499 free pages, so better than
regular SLUB. But it seems that the memory is more fragmented as
allocations fail more often.

Hope this helps. Let me know if you want to test something else.

Cheers.

-- 
Damien Le Moal
Western Digital Research

Re: Deprecating and removing SLOB

[Damien Le Moal]

On 11/15/22 13:24, Damien Le Moal wrote:
> On 11/14/22 23:47, Hyeonggon Yoo wrote:
>> On Mon, Nov 14, 2022 at 08:35:31PM +0900, Damien Le Moal wrote:
>>> On 11/14/22 18:36, Vlastimil Babka wrote:
>>>> On 11/14/22 06:48, Damien Le Moal wrote:
>>>>> On 11/14/22 10:55, Damien Le Moal wrote:
>>>>>> On 11/12/22 05:46, Conor Dooley wrote:
>>>>>>> On Fri, Nov 11, 2022 at 11:33:30AM +0100, Vlastimil Babka wrote:
>>>>>>>> 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/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
>>>>>>>
>>>>>>>>
>>>>>>>> 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/riscv/configs/nommu_virt_defconfig:CONFIG_EXPERT=y
>>>>>>>
>>>>>>> I suppose there's not really a concern with the virt defconfig, but I
>>>>>>> did check the output of `make nommu_k210_defconfig" and despite not
>>>>>>> having expert it seems to end up CONFIG_SLOB=y in the generated .config.
>>>>>>>
>>>>>>> I do have a board with a k210 so I checked with s/SLOB/SLUB and it still
>>>>>>> boots etc, but I have no workloads or w/e to run on it.
>>>>>>
>>>>>> I sent a patch to change the k210 defconfig to using SLUB. However...
>>>>
>>>> Thanks!
>>>>
>>>>>> The current default config using SLOB gives about 630 free memory pages
>>>>>> after boot (cat /proc/vmstat). Switching to SLUB, this is down to about
>>>>>> 400 free memory pages (CONFIG_SLUB_CPU_PARTIAL is off).
>>>>
>>>> Thanks for the testing! How much RAM does the system have btw? I found 8MB
>>>> somewhere, is that correct?
>>>
>>> Yep, 8MB, that's it.
>>>
>>>> So 230 pages that's a ~920 kB difference. Last time we saw less  dramatic
>>>> difference [1]. But that was looking at Slab pages, not free pages. The
>>>> extra overhead could be also in percpu allocations, code etc.
>>>>
>>>>>> This is with a buildroot kernel 5.19 build including a shell and sd-card
>>>>>> boot. With SLUB, I get clean boots and a shell prompt as expected. But I
>>>>>> definitely see more errors with shell commands failing due to allocation
>>>>>> failures for the shell process fork. So as far as the K210 is concerned,
>>>>>> switching to SLUB is not ideal.
>>>>>>
>>>>>> I would not want to hold on kernel mm improvements because of this toy
>>>>>> k210 though, so I am not going to prevent SLOB deprecation. I just wish
>>>>>> SLUB itself used less memory :)
>>>>>
>>>>> Did further tests with kernel 6.0.1:
>>>>> * SLOB: 630 free pages after boot, shell working (occasional shell fork
>>>>> failure happen though)
>>>>> * SLAB: getting memory allocation for order 7 failures on boot already
>>>>> (init process). Shell barely working (high frequency of shell command fork
>>>>> failures)
>>>
>>> I forgot to add here that the system was down to about 500 free pages
>>> after boot (again from the shell with "cat /proc/vmstat").
>>>
>>>>> * SLUB: getting memory allocation for order 7 failures on boot. I do get a
>>>>> shell prompt but cannot run any shell command that involves forking a new
>>>>> process.
>>>
>>> For both slab and slub, I had cpu partial off, debug off and slab merge
>>> on, as I suspected that would lead to less memory overhead.
>>> I suspected memory fragmentation may be an issue but doing
>>>
>>> echo 3 > /proc/sys/vm/drop_caches
>>>
>>> before trying a shell command did not help much at all (it usually does on
>>> that board with SLOB). Note that this is all with buildroot, so this echo
>>> & redirect always works as it does not cause a shell fork.
>>>
>>>>>
>>>>> So if we want to keep the k210 support functional with a shell, we need
>>>>> slob. If we reduce that board support to only one application started as
>>>>> the init process, then I guess anything is OK.
>>>>
>>>> In [1] it was possible to save some more memory with more tuning. Some of
>>>> that required boot parameters and other code changes. In another reply [2] I
>>>> considered adding something like SLUB_TINY to take care of all that, so
>>>> looks like it would make sense to proceed with that.
>>>
>>> If you want me to test something, let me know.
>>
>> Would you try this please?
>>
>> diff --git a/mm/slub.c b/mm/slub.c
>> index a24b71041b26..1c36c4b9aaa0 100644
>> --- a/mm/slub.c
>> +++ b/mm/slub.c
>> @@ -4367,9 +4367,7 @@ static int kmem_cache_open(struct kmem_cache *s, slab_flags_t flags)
>>  	 * The larger the object size is, the more slabs we want on the partial
>>  	 * list to avoid pounding the page allocator excessively.
>>  	 */
>> -	s->min_partial = min_t(unsigned long, MAX_PARTIAL, ilog2(s->size) / 2);
>> -	s->min_partial = max_t(unsigned long, MIN_PARTIAL, s->min_partial);
>> -
>> +	s->min_partial = 0;
>>  	set_cpu_partial(s);
>>  
>>  #ifdef CONFIG_NUMA
>>
>>
>> and booting with and without boot parameter slub_max_order=0?
> 
> Test notes: I used Linus 6.1-rc5 as the base. That is the only thing I
> changed in buildroot default config for the sipeed maix bit card, booting
> with SD card. The test is: booting and run "cat /proc/vmstat" and register
> the nr_free_pages value. I repeated the boot + cat 3 to 4 times for each case.
> 
> Here are the results:
> 
> 6.1-rc5, SLOB:
>     - 623 free pages
>     - 629 free pages
>     - 629 free pages
> 6.1-rc5, SLUB:
>     - 448 free pages
>     - 448 free pages
>     - 429 free pages
> 6.1-rc5, SLUB + slub_max_order=0:
>     - Init error, shell prompt but no shell command working
>     - Init error, no shell prompt
>     - 508 free pages
>     - Init error, shell prompt but no shell command working
> 6.1-rc5, SLUB + patch:
>     - Init error, shell prompt but no shell command working
>     - 433 free pages
>     - 448 free pages
>     - 423 free pages
> 6.1-rc5, SLUB + slub_max_order=0 + patch:
>     - Init error, no shell prompt
>     - Init error, shell prompt, 499 free pages
>     - Init error, shell prompt but no shell command working
>     - Init error, no shell prompt
> 
> No changes for SLOB results, expected.
> 
> For default SLUB, I did get all clean boots this time and could run the
> cat command. But I do see shell fork failures if I keep running commands.
> 
> For SLUB + slub_max_order=0, I only got one clean boot with 508 free
> pages. Remaining runs failed to give a shell prompt or allow running cat
> command. For the clean boot, I do see higher number of free pages.
> 
> SLUB with the patch was nearly identical to SLUB without the patch.
> 
> And SLUB+patch+slub_max_order=0 gave again a lot of errors/bad boot. I
> could run the cat command only once, giving 499 free pages, so better than
> regular SLUB. But it seems that the memory is more fragmented as
> allocations fail more often.

Note about the last case (SLUB+patch+slub_max_order=0). Here are the
messages I got when the init shell process fork failed:

[    1.217998] nommu: Allocation of length 491520 from process 1 (sh) failed
[    1.224098] active_anon:0 inactive_anon:0 isolated_anon:0
[    1.224098]  active_file:5 inactive_file:12 isolated_file:0
[    1.224098]  unevictable:0 dirty:0 writeback:0
[    1.224098]  slab_reclaimable:38 slab_unreclaimable:459
[    1.224098]  mapped:0 shmem:0 pagetables:0
[    1.224098]  sec_pagetables:0 bounce:0
[    1.224098]  kernel_misc_reclaimable:0
[    1.224098]  free:859 free_pcp:0 free_cma:0
[    1.260419] Node 0 active_anon:0kB inactive_anon:0kB active_file:20kB
inactive_file:48kB unevictable:0kB isolated(anon):0kB isolated(file):0kB
mapped:0kB dirty:0kB writeback:0kB shmem:0kB writeback_tmp:0kB
kernel_stack:576kB pagetables:0kB sec_pagetables:0kB all_unreclaimable? no
[    1.285147] DMA32 free:3436kB boost:0kB min:312kB low:388kB high:464kB
reserved_highatomic:0KB active_anon:0kB inactive_anon:0kB active_file:0kB
inactive_file:28kB unevictable:0kB writepending:0kB present:8192kB
managed:6240kB mlocked:0kB bounce:0kB free_pcp:0kB local_pcp:0kB free_cma:0kB
[    1.310654] lowmem_reserve[]: 0 0 0
[    1.314089] DMA32: 17*4kB (U) 10*8kB (U) 7*16kB (U) 6*32kB (U) 11*64kB
(U) 6*128kB (U) 6*256kB (U) 0*512kB 0*1024kB 0*2048kB 0*4096kB = 3460kB
[    1.326883] 33 total pagecache pages
[    1.330420] binfmt_flat: Unable to allocate RAM for process text/data,
errno -12
[    1.337858] Kernel panic - not syncing: Attempted to kill init!
exitcode=0x0000000b


-- 
Damien Le Moal
Western Digital Research

Re: Deprecating and removing SLOB

[Matthew Wilcox]

On Tue, Nov 15, 2022 at 01:28:14PM +0900, Damien Le Moal wrote:
> On 11/15/22 13:24, Damien Le Moal wrote:
> > 6.1-rc5, SLOB:
> >     - 623 free pages
> >     - 629 free pages
> >     - 629 free pages
> > 6.1-rc5, SLUB:
> >     - 448 free pages
> >     - 448 free pages
> >     - 429 free pages
> > 6.1-rc5, SLUB + slub_max_order=0:
> >     - Init error, shell prompt but no shell command working
> >     - Init error, no shell prompt
> >     - 508 free pages
> >     - Init error, shell prompt but no shell command working
> > 6.1-rc5, SLUB + patch:
> >     - Init error, shell prompt but no shell command working
> >     - 433 free pages
> >     - 448 free pages
> >     - 423 free pages
> > 6.1-rc5, SLUB + slub_max_order=0 + patch:
> >     - Init error, no shell prompt
> >     - Init error, shell prompt, 499 free pages
> >     - Init error, shell prompt but no shell command working
> >     - Init error, no shell prompt
> > 
> > No changes for SLOB results, expected.
> > 
> > For default SLUB, I did get all clean boots this time and could run the
> > cat command. But I do see shell fork failures if I keep running commands.
> > 
> > For SLUB + slub_max_order=0, I only got one clean boot with 508 free
> > pages. Remaining runs failed to give a shell prompt or allow running cat
> > command. For the clean boot, I do see higher number of free pages.
> > 
> > SLUB with the patch was nearly identical to SLUB without the patch.
> > 
> > And SLUB+patch+slub_max_order=0 gave again a lot of errors/bad boot. I
> > could run the cat command only once, giving 499 free pages, so better than
> > regular SLUB. But it seems that the memory is more fragmented as
> > allocations fail more often.
> 
> Note about the last case (SLUB+patch+slub_max_order=0). Here are the
> messages I got when the init shell process fork failed:
> 
> [    1.217998] nommu: Allocation of length 491520 from process 1 (sh) failed
> [    1.224098] active_anon:0 inactive_anon:0 isolated_anon:0
> [    1.224098]  active_file:5 inactive_file:12 isolated_file:0
> [    1.224098]  unevictable:0 dirty:0 writeback:0
> [    1.224098]  slab_reclaimable:38 slab_unreclaimable:459
> [    1.224098]  mapped:0 shmem:0 pagetables:0
> [    1.224098]  sec_pagetables:0 bounce:0
> [    1.224098]  kernel_misc_reclaimable:0
> [    1.224098]  free:859 free_pcp:0 free_cma:0
> [    1.260419] Node 0 active_anon:0kB inactive_anon:0kB active_file:20kB
> inactive_file:48kB unevictable:0kB isolated(anon):0kB isolated(file):0kB
> mapped:0kB dirty:0kB writeback:0kB shmem:0kB writeback_tmp:0kB
> kernel_stack:576kB pagetables:0kB sec_pagetables:0kB all_unreclaimable? no
> [    1.285147] DMA32 free:3436kB boost:0kB min:312kB low:388kB high:464kB
> reserved_highatomic:0KB active_anon:0kB inactive_anon:0kB active_file:0kB
> inactive_file:28kB unevictable:0kB writepending:0kB present:8192kB
> managed:6240kB mlocked:0kB bounce:0kB free_pcp:0kB local_pcp:0kB free_cma:0kB
> [    1.310654] lowmem_reserve[]: 0 0 0
> [    1.314089] DMA32: 17*4kB (U) 10*8kB (U) 7*16kB (U) 6*32kB (U) 11*64kB
> (U) 6*128kB (U) 6*256kB (U) 0*512kB 0*1024kB 0*2048kB 0*4096kB = 3460kB
> [    1.326883] 33 total pagecache pages
> [    1.330420] binfmt_flat: Unable to allocate RAM for process text/data,
> errno -12

What you're seeing here is memory fragmentation.  There's more than 512kB
of memory available, but nommu requires it to be contiguous, and it's
not.  This is pretty bad, really.  We didn't even finish starting up
and already we've managed to allocate at least one page from each of
the 16 512kB chunks which existed.  Commit df48a5f7a3bb was supposed
to improve matters by making exact allocations reassemble once they
were freed.  Maybe the problem is entirely different.

Re: Deprecating and removing SLOB

[Damien Le Moal]

On 2022/11/16 16:57, Matthew Wilcox wrote:
> On Tue, Nov 15, 2022 at 01:28:14PM +0900, Damien Le Moal wrote:
>> On 11/15/22 13:24, Damien Le Moal wrote:
>>> 6.1-rc5, SLOB:
>>>     - 623 free pages
>>>     - 629 free pages
>>>     - 629 free pages
>>> 6.1-rc5, SLUB:
>>>     - 448 free pages
>>>     - 448 free pages
>>>     - 429 free pages
>>> 6.1-rc5, SLUB + slub_max_order=0:
>>>     - Init error, shell prompt but no shell command working
>>>     - Init error, no shell prompt
>>>     - 508 free pages
>>>     - Init error, shell prompt but no shell command working
>>> 6.1-rc5, SLUB + patch:
>>>     - Init error, shell prompt but no shell command working
>>>     - 433 free pages
>>>     - 448 free pages
>>>     - 423 free pages
>>> 6.1-rc5, SLUB + slub_max_order=0 + patch:
>>>     - Init error, no shell prompt
>>>     - Init error, shell prompt, 499 free pages
>>>     - Init error, shell prompt but no shell command working
>>>     - Init error, no shell prompt
>>>
>>> No changes for SLOB results, expected.
>>>
>>> For default SLUB, I did get all clean boots this time and could run the
>>> cat command. But I do see shell fork failures if I keep running commands.
>>>
>>> For SLUB + slub_max_order=0, I only got one clean boot with 508 free
>>> pages. Remaining runs failed to give a shell prompt or allow running cat
>>> command. For the clean boot, I do see higher number of free pages.
>>>
>>> SLUB with the patch was nearly identical to SLUB without the patch.
>>>
>>> And SLUB+patch+slub_max_order=0 gave again a lot of errors/bad boot. I
>>> could run the cat command only once, giving 499 free pages, so better than
>>> regular SLUB. But it seems that the memory is more fragmented as
>>> allocations fail more often.
>>
>> Note about the last case (SLUB+patch+slub_max_order=0). Here are the
>> messages I got when the init shell process fork failed:
>>
>> [    1.217998] nommu: Allocation of length 491520 from process 1 (sh) failed
>> [    1.224098] active_anon:0 inactive_anon:0 isolated_anon:0
>> [    1.224098]  active_file:5 inactive_file:12 isolated_file:0
>> [    1.224098]  unevictable:0 dirty:0 writeback:0
>> [    1.224098]  slab_reclaimable:38 slab_unreclaimable:459
>> [    1.224098]  mapped:0 shmem:0 pagetables:0
>> [    1.224098]  sec_pagetables:0 bounce:0
>> [    1.224098]  kernel_misc_reclaimable:0
>> [    1.224098]  free:859 free_pcp:0 free_cma:0
>> [    1.260419] Node 0 active_anon:0kB inactive_anon:0kB active_file:20kB
>> inactive_file:48kB unevictable:0kB isolated(anon):0kB isolated(file):0kB
>> mapped:0kB dirty:0kB writeback:0kB shmem:0kB writeback_tmp:0kB
>> kernel_stack:576kB pagetables:0kB sec_pagetables:0kB all_unreclaimable? no
>> [    1.285147] DMA32 free:3436kB boost:0kB min:312kB low:388kB high:464kB
>> reserved_highatomic:0KB active_anon:0kB inactive_anon:0kB active_file:0kB
>> inactive_file:28kB unevictable:0kB writepending:0kB present:8192kB
>> managed:6240kB mlocked:0kB bounce:0kB free_pcp:0kB local_pcp:0kB free_cma:0kB
>> [    1.310654] lowmem_reserve[]: 0 0 0
>> [    1.314089] DMA32: 17*4kB (U) 10*8kB (U) 7*16kB (U) 6*32kB (U) 11*64kB
>> (U) 6*128kB (U) 6*256kB (U) 0*512kB 0*1024kB 0*2048kB 0*4096kB = 3460kB
>> [    1.326883] 33 total pagecache pages
>> [    1.330420] binfmt_flat: Unable to allocate RAM for process text/data,
>> errno -12
> 
> What you're seeing here is memory fragmentation.  There's more than 512kB
> of memory available, but nommu requires it to be contiguous, and it's
> not.  This is pretty bad, really.  We didn't even finish starting up
> and already we've managed to allocate at least one page from each of
> the 16 512kB chunks which existed.  Commit df48a5f7a3bb was supposed
> to improve matters by making exact allocations reassemble once they
> were freed.  Maybe the problem is entirely different.

I suspected something like this when seeing the reported "free:859" :)
What I can try next is booting without SD card and the bare minimum set of
drivers to see if the fragmentation is still there or not. Would that help ?
These one page allocations may be for device drivers so never freed, no ?

-- 
Damien Le Moal
Western Digital Research

Re: Deprecating and removing SLOB

[Vlastimil Babka]

On 11/15/22 05:24, Damien Le Moal wrote:
> On 11/14/22 23:47, Hyeonggon Yoo wrote:
>> On Mon, Nov 14, 2022 at 08:35:31PM +0900, Damien Le Moal wrote:
>>> On 11/14/22 18:36, Vlastimil Babka wrote:
>>>> On 11/14/22 06:48, Damien Le Moal wrote:
>>>>> On 11/14/22 10:55, Damien Le Moal wrote:
>>>>>> On 11/12/22 05:46, Conor Dooley wrote:
>>>>>>> On Fri, Nov 11, 2022 at 11:33:30AM +0100, Vlastimil Babka wrote:
>>>>>>>> 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/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
>>>>>>>
>>>>>>>>
>>>>>>>> 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/riscv/configs/nommu_virt_defconfig:CONFIG_EXPERT=y
>>>>>>>
>>>>>>> I suppose there's not really a concern with the virt defconfig, but I
>>>>>>> did check the output of `make nommu_k210_defconfig" and despite not
>>>>>>> having expert it seems to end up CONFIG_SLOB=y in the generated .config.
>>>>>>>
>>>>>>> I do have a board with a k210 so I checked with s/SLOB/SLUB and it still
>>>>>>> boots etc, but I have no workloads or w/e to run on it.
>>>>>>
>>>>>> I sent a patch to change the k210 defconfig to using SLUB. However...
>>>>
>>>> Thanks!
>>>>
>>>>>> The current default config using SLOB gives about 630 free memory pages
>>>>>> after boot (cat /proc/vmstat). Switching to SLUB, this is down to about
>>>>>> 400 free memory pages (CONFIG_SLUB_CPU_PARTIAL is off).
>>>>
>>>> Thanks for the testing! How much RAM does the system have btw? I found 8MB
>>>> somewhere, is that correct?
>>>
>>> Yep, 8MB, that's it.
>>>
>>>> So 230 pages that's a ~920 kB difference. Last time we saw less  dramatic
>>>> difference [1]. But that was looking at Slab pages, not free pages. The
>>>> extra overhead could be also in percpu allocations, code etc.
>>>>
>>>>>> This is with a buildroot kernel 5.19 build including a shell and sd-card
>>>>>> boot. With SLUB, I get clean boots and a shell prompt as expected. But I
>>>>>> definitely see more errors with shell commands failing due to allocation
>>>>>> failures for the shell process fork. So as far as the K210 is concerned,
>>>>>> switching to SLUB is not ideal.
>>>>>>
>>>>>> I would not want to hold on kernel mm improvements because of this toy
>>>>>> k210 though, so I am not going to prevent SLOB deprecation. I just wish
>>>>>> SLUB itself used less memory :)
>>>>>
>>>>> Did further tests with kernel 6.0.1:
>>>>> * SLOB: 630 free pages after boot, shell working (occasional shell fork
>>>>> failure happen though)
>>>>> * SLAB: getting memory allocation for order 7 failures on boot already
>>>>> (init process). Shell barely working (high frequency of shell command fork
>>>>> failures)
>>>
>>> I forgot to add here that the system was down to about 500 free pages
>>> after boot (again from the shell with "cat /proc/vmstat").
>>>
>>>>> * SLUB: getting memory allocation for order 7 failures on boot. I do get a
>>>>> shell prompt but cannot run any shell command that involves forking a new
>>>>> process.
>>>
>>> For both slab and slub, I had cpu partial off, debug off and slab merge
>>> on, as I suspected that would lead to less memory overhead.
>>> I suspected memory fragmentation may be an issue but doing
>>>
>>> echo 3 > /proc/sys/vm/drop_caches
>>>
>>> before trying a shell command did not help much at all (it usually does on
>>> that board with SLOB). Note that this is all with buildroot, so this echo
>>> & redirect always works as it does not cause a shell fork.
>>>
>>>>>
>>>>> So if we want to keep the k210 support functional with a shell, we need
>>>>> slob. If we reduce that board support to only one application started as
>>>>> the init process, then I guess anything is OK.
>>>>
>>>> In [1] it was possible to save some more memory with more tuning. Some of
>>>> that required boot parameters and other code changes. In another reply [2] I
>>>> considered adding something like SLUB_TINY to take care of all that, so
>>>> looks like it would make sense to proceed with that.
>>>
>>> If you want me to test something, let me know.
>> 
>> Would you try this please?
>> 
>> diff --git a/mm/slub.c b/mm/slub.c
>> index a24b71041b26..1c36c4b9aaa0 100644
>> --- a/mm/slub.c
>> +++ b/mm/slub.c
>> @@ -4367,9 +4367,7 @@ static int kmem_cache_open(struct kmem_cache *s, slab_flags_t flags)
>>  	 * The larger the object size is, the more slabs we want on the partial
>>  	 * list to avoid pounding the page allocator excessively.
>>  	 */
>> -	s->min_partial = min_t(unsigned long, MAX_PARTIAL, ilog2(s->size) / 2);
>> -	s->min_partial = max_t(unsigned long, MIN_PARTIAL, s->min_partial);
>> -
>> +	s->min_partial = 0;
>>  	set_cpu_partial(s);
>>  
>>  #ifdef CONFIG_NUMA
>> 
>> 
>> and booting with and without boot parameter slub_max_order=0?
> 
> Test notes: I used Linus 6.1-rc5 as the base. That is the only thing I
> changed in buildroot default config for the sipeed maix bit card, booting
> with SD card. The test is: booting and run "cat /proc/vmstat" and register
> the nr_free_pages value. I repeated the boot + cat 3 to 4 times for each case.
> 
> Here are the results:
> 
> 6.1-rc5, SLOB:
>     - 623 free pages
>     - 629 free pages
>     - 629 free pages
> 6.1-rc5, SLUB:
>     - 448 free pages
>     - 448 free pages
>     - 429 free pages
> 6.1-rc5, SLUB + slub_max_order=0:
>     - Init error, shell prompt but no shell command working
>     - Init error, no shell prompt
>     - 508 free pages
>     - Init error, shell prompt but no shell command working
> 6.1-rc5, SLUB + patch:
>     - Init error, shell prompt but no shell command working
>     - 433 free pages
>     - 448 free pages
>     - 423 free pages
> 6.1-rc5, SLUB + slub_max_order=0 + patch:
>     - Init error, no shell prompt
>     - Init error, shell prompt, 499 free pages
>     - Init error, shell prompt but no shell command working
>     - Init error, no shell prompt
> 
> No changes for SLOB results, expected.
> 
> For default SLUB, I did get all clean boots this time and could run the
> cat command. But I do see shell fork failures if I keep running commands.
> 
> For SLUB + slub_max_order=0, I only got one clean boot with 508 free
> pages. Remaining runs failed to give a shell prompt or allow running cat
> command. For the clean boot, I do see higher number of free pages.
> 
> SLUB with the patch was nearly identical to SLUB without the patch.
> 
> And SLUB+patch+slub_max_order=0 gave again a lot of errors/bad boot. I
> could run the cat command only once, giving 499 free pages, so better than
> regular SLUB. But it seems that the memory is more fragmented as
> allocations fail more often.
> 
> Hope this helps. Let me know if you want to test something else.

Could you please try this branch with CONFIG_SLUB_TINY=y?
https://git.kernel.org/pub/scm/linux/kernel/git/vbabka/linux.git/log/?h=slub-tiny-v1r0

Seeing your results I didn't modify default slub_max_order by this new
CONFIG (yet?) so maybe after trying the default, trying then also with
manual slub_max_order=0 and slub_max_order=1 would be useful too. Otherwise
it should be all changes to lower SLUB memory footprint. Hopefully it will
be visible in the number of free pages. But if fragmentation is an issue, it
might not be enough. BTW, during boot there should be a line "Built X
zonelists, mobility grouping ..." can you grep for it and provide please, I
wonder if mobility grouping ends up being off or on on that system.

Thanks!

> Cheers.
> 

Re: Deprecating and removing SLOB

[Damien Le Moal]

On 2022/11/17 2:51, Vlastimil Babka wrote:
> On 11/15/22 05:24, Damien Le Moal wrote:
>> On 11/14/22 23:47, Hyeonggon Yoo wrote:
>>> On Mon, Nov 14, 2022 at 08:35:31PM +0900, Damien Le Moal wrote:
>>>> On 11/14/22 18:36, Vlastimil Babka wrote:
>>>>> On 11/14/22 06:48, Damien Le Moal wrote:
>>>>>> On 11/14/22 10:55, Damien Le Moal wrote:
>>>>>>> On 11/12/22 05:46, Conor Dooley wrote:
>>>>>>>> On Fri, Nov 11, 2022 at 11:33:30AM +0100, Vlastimil Babka wrote:
>>>>>>>>> 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/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
>>>>>>>>
>>>>>>>>>
>>>>>>>>> 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/riscv/configs/nommu_virt_defconfig:CONFIG_EXPERT=y
>>>>>>>>
>>>>>>>> I suppose there's not really a concern with the virt defconfig, but I
>>>>>>>> did check the output of `make nommu_k210_defconfig" and despite not
>>>>>>>> having expert it seems to end up CONFIG_SLOB=y in the generated .config.
>>>>>>>>
>>>>>>>> I do have a board with a k210 so I checked with s/SLOB/SLUB and it still
>>>>>>>> boots etc, but I have no workloads or w/e to run on it.
>>>>>>>
>>>>>>> I sent a patch to change the k210 defconfig to using SLUB. However...
>>>>>
>>>>> Thanks!
>>>>>
>>>>>>> The current default config using SLOB gives about 630 free memory pages
>>>>>>> after boot (cat /proc/vmstat). Switching to SLUB, this is down to about
>>>>>>> 400 free memory pages (CONFIG_SLUB_CPU_PARTIAL is off).
>>>>>
>>>>> Thanks for the testing! How much RAM does the system have btw? I found 8MB
>>>>> somewhere, is that correct?
>>>>
>>>> Yep, 8MB, that's it.
>>>>
>>>>> So 230 pages that's a ~920 kB difference. Last time we saw less  dramatic
>>>>> difference [1]. But that was looking at Slab pages, not free pages. The
>>>>> extra overhead could be also in percpu allocations, code etc.
>>>>>
>>>>>>> This is with a buildroot kernel 5.19 build including a shell and sd-card
>>>>>>> boot. With SLUB, I get clean boots and a shell prompt as expected. But I
>>>>>>> definitely see more errors with shell commands failing due to allocation
>>>>>>> failures for the shell process fork. So as far as the K210 is concerned,
>>>>>>> switching to SLUB is not ideal.
>>>>>>>
>>>>>>> I would not want to hold on kernel mm improvements because of this toy
>>>>>>> k210 though, so I am not going to prevent SLOB deprecation. I just wish
>>>>>>> SLUB itself used less memory :)
>>>>>>
>>>>>> Did further tests with kernel 6.0.1:
>>>>>> * SLOB: 630 free pages after boot, shell working (occasional shell fork
>>>>>> failure happen though)
>>>>>> * SLAB: getting memory allocation for order 7 failures on boot already
>>>>>> (init process). Shell barely working (high frequency of shell command fork
>>>>>> failures)
>>>>
>>>> I forgot to add here that the system was down to about 500 free pages
>>>> after boot (again from the shell with "cat /proc/vmstat").
>>>>
>>>>>> * SLUB: getting memory allocation for order 7 failures on boot. I do get a
>>>>>> shell prompt but cannot run any shell command that involves forking a new
>>>>>> process.
>>>>
>>>> For both slab and slub, I had cpu partial off, debug off and slab merge
>>>> on, as I suspected that would lead to less memory overhead.
>>>> I suspected memory fragmentation may be an issue but doing
>>>>
>>>> echo 3 > /proc/sys/vm/drop_caches
>>>>
>>>> before trying a shell command did not help much at all (it usually does on
>>>> that board with SLOB). Note that this is all with buildroot, so this echo
>>>> & redirect always works as it does not cause a shell fork.
>>>>
>>>>>>
>>>>>> So if we want to keep the k210 support functional with a shell, we need
>>>>>> slob. If we reduce that board support to only one application started as
>>>>>> the init process, then I guess anything is OK.
>>>>>
>>>>> In [1] it was possible to save some more memory with more tuning. Some of
>>>>> that required boot parameters and other code changes. In another reply [2] I
>>>>> considered adding something like SLUB_TINY to take care of all that, so
>>>>> looks like it would make sense to proceed with that.
>>>>
>>>> If you want me to test something, let me know.
>>>
>>> Would you try this please?
>>>
>>> diff --git a/mm/slub.c b/mm/slub.c
>>> index a24b71041b26..1c36c4b9aaa0 100644
>>> --- a/mm/slub.c
>>> +++ b/mm/slub.c
>>> @@ -4367,9 +4367,7 @@ static int kmem_cache_open(struct kmem_cache *s, slab_flags_t flags)
>>>  	 * The larger the object size is, the more slabs we want on the partial
>>>  	 * list to avoid pounding the page allocator excessively.
>>>  	 */
>>> -	s->min_partial = min_t(unsigned long, MAX_PARTIAL, ilog2(s->size) / 2);
>>> -	s->min_partial = max_t(unsigned long, MIN_PARTIAL, s->min_partial);
>>> -
>>> +	s->min_partial = 0;
>>>  	set_cpu_partial(s);
>>>  
>>>  #ifdef CONFIG_NUMA
>>>
>>>
>>> and booting with and without boot parameter slub_max_order=0?
>>
>> Test notes: I used Linus 6.1-rc5 as the base. That is the only thing I
>> changed in buildroot default config for the sipeed maix bit card, booting
>> with SD card. The test is: booting and run "cat /proc/vmstat" and register
>> the nr_free_pages value. I repeated the boot + cat 3 to 4 times for each case.
>>
>> Here are the results:
>>
>> 6.1-rc5, SLOB:
>>     - 623 free pages
>>     - 629 free pages
>>     - 629 free pages
>> 6.1-rc5, SLUB:
>>     - 448 free pages
>>     - 448 free pages
>>     - 429 free pages
>> 6.1-rc5, SLUB + slub_max_order=0:
>>     - Init error, shell prompt but no shell command working
>>     - Init error, no shell prompt
>>     - 508 free pages
>>     - Init error, shell prompt but no shell command working
>> 6.1-rc5, SLUB + patch:
>>     - Init error, shell prompt but no shell command working
>>     - 433 free pages
>>     - 448 free pages
>>     - 423 free pages
>> 6.1-rc5, SLUB + slub_max_order=0 + patch:
>>     - Init error, no shell prompt
>>     - Init error, shell prompt, 499 free pages
>>     - Init error, shell prompt but no shell command working
>>     - Init error, no shell prompt
>>
>> No changes for SLOB results, expected.
>>
>> For default SLUB, I did get all clean boots this time and could run the
>> cat command. But I do see shell fork failures if I keep running commands.
>>
>> For SLUB + slub_max_order=0, I only got one clean boot with 508 free
>> pages. Remaining runs failed to give a shell prompt or allow running cat
>> command. For the clean boot, I do see higher number of free pages.
>>
>> SLUB with the patch was nearly identical to SLUB without the patch.
>>
>> And SLUB+patch+slub_max_order=0 gave again a lot of errors/bad boot. I
>> could run the cat command only once, giving 499 free pages, so better than
>> regular SLUB. But it seems that the memory is more fragmented as
>> allocations fail more often.
>>
>> Hope this helps. Let me know if you want to test something else.
> 
> Could you please try this branch with CONFIG_SLUB_TINY=y?
> https://git.kernel.org/pub/scm/linux/kernel/git/vbabka/linux.git/log/?h=slub-tiny-v1r0
> 
> Seeing your results I didn't modify default slub_max_order by this new
> CONFIG (yet?) so maybe after trying the default, trying then also with
> manual slub_max_order=0 and slub_max_order=1 would be useful too. Otherwise
> it should be all changes to lower SLUB memory footprint. Hopefully it will
> be visible in the number of free pages. But if fragmentation is an issue, it
> might not be enough. BTW, during boot there should be a line "Built X
> zonelists, mobility grouping ..." can you grep for it and provide please, I
> wonder if mobility grouping ends up being off or on on that system.

OK. Will try as soon as I can (before end of week hopefully). My pipeline is a
little crowded right now :)

> 
> Thanks!
> 
>> Cheers.
>>
> 

-- 
Damien Le Moal
Western Digital Research

Re: Deprecating and removing SLOB

[Damien Le Moal]

On 11/17/22 02:51, Vlastimil Babka wrote:
> On 11/15/22 05:24, Damien Le Moal wrote:
>> On 11/14/22 23:47, Hyeonggon Yoo wrote:
>>> On Mon, Nov 14, 2022 at 08:35:31PM +0900, Damien Le Moal wrote:
>>>> On 11/14/22 18:36, Vlastimil Babka wrote:
>>>>> On 11/14/22 06:48, Damien Le Moal wrote:
>>>>>> On 11/14/22 10:55, Damien Le Moal wrote:
>>>>>>> On 11/12/22 05:46, Conor Dooley wrote:
>>>>>>>> On Fri, Nov 11, 2022 at 11:33:30AM +0100, Vlastimil Babka wrote:
>>>>>>>>> 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/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
>>>>>>>>
>>>>>>>>>
>>>>>>>>> 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/riscv/configs/nommu_virt_defconfig:CONFIG_EXPERT=y
>>>>>>>>
>>>>>>>> I suppose there's not really a concern with the virt defconfig, but I
>>>>>>>> did check the output of `make nommu_k210_defconfig" and despite not
>>>>>>>> having expert it seems to end up CONFIG_SLOB=y in the generated .config.
>>>>>>>>
>>>>>>>> I do have a board with a k210 so I checked with s/SLOB/SLUB and it still
>>>>>>>> boots etc, but I have no workloads or w/e to run on it.
>>>>>>>
>>>>>>> I sent a patch to change the k210 defconfig to using SLUB. However...
>>>>>
>>>>> Thanks!
>>>>>
>>>>>>> The current default config using SLOB gives about 630 free memory pages
>>>>>>> after boot (cat /proc/vmstat). Switching to SLUB, this is down to about
>>>>>>> 400 free memory pages (CONFIG_SLUB_CPU_PARTIAL is off).
>>>>>
>>>>> Thanks for the testing! How much RAM does the system have btw? I found 8MB
>>>>> somewhere, is that correct?
>>>>
>>>> Yep, 8MB, that's it.
>>>>
>>>>> So 230 pages that's a ~920 kB difference. Last time we saw less  dramatic
>>>>> difference [1]. But that was looking at Slab pages, not free pages. The
>>>>> extra overhead could be also in percpu allocations, code etc.
>>>>>
>>>>>>> This is with a buildroot kernel 5.19 build including a shell and sd-card
>>>>>>> boot. With SLUB, I get clean boots and a shell prompt as expected. But I
>>>>>>> definitely see more errors with shell commands failing due to allocation
>>>>>>> failures for the shell process fork. So as far as the K210 is concerned,
>>>>>>> switching to SLUB is not ideal.
>>>>>>>
>>>>>>> I would not want to hold on kernel mm improvements because of this toy
>>>>>>> k210 though, so I am not going to prevent SLOB deprecation. I just wish
>>>>>>> SLUB itself used less memory :)
>>>>>>
>>>>>> Did further tests with kernel 6.0.1:
>>>>>> * SLOB: 630 free pages after boot, shell working (occasional shell fork
>>>>>> failure happen though)
>>>>>> * SLAB: getting memory allocation for order 7 failures on boot already
>>>>>> (init process). Shell barely working (high frequency of shell command fork
>>>>>> failures)
>>>>
>>>> I forgot to add here that the system was down to about 500 free pages
>>>> after boot (again from the shell with "cat /proc/vmstat").
>>>>
>>>>>> * SLUB: getting memory allocation for order 7 failures on boot. I do get a
>>>>>> shell prompt but cannot run any shell command that involves forking a new
>>>>>> process.
>>>>
>>>> For both slab and slub, I had cpu partial off, debug off and slab merge
>>>> on, as I suspected that would lead to less memory overhead.
>>>> I suspected memory fragmentation may be an issue but doing
>>>>
>>>> echo 3 > /proc/sys/vm/drop_caches
>>>>
>>>> before trying a shell command did not help much at all (it usually does on
>>>> that board with SLOB). Note that this is all with buildroot, so this echo
>>>> & redirect always works as it does not cause a shell fork.
>>>>
>>>>>>
>>>>>> So if we want to keep the k210 support functional with a shell, we need
>>>>>> slob. If we reduce that board support to only one application started as
>>>>>> the init process, then I guess anything is OK.
>>>>>
>>>>> In [1] it was possible to save some more memory with more tuning. Some of
>>>>> that required boot parameters and other code changes. In another reply [2] I
>>>>> considered adding something like SLUB_TINY to take care of all that, so
>>>>> looks like it would make sense to proceed with that.
>>>>
>>>> If you want me to test something, let me know.
>>>
>>> Would you try this please?
>>>
>>> diff --git a/mm/slub.c b/mm/slub.c
>>> index a24b71041b26..1c36c4b9aaa0 100644
>>> --- a/mm/slub.c
>>> +++ b/mm/slub.c
>>> @@ -4367,9 +4367,7 @@ static int kmem_cache_open(struct kmem_cache *s, slab_flags_t flags)
>>>  	 * The larger the object size is, the more slabs we want on the partial
>>>  	 * list to avoid pounding the page allocator excessively.
>>>  	 */
>>> -	s->min_partial = min_t(unsigned long, MAX_PARTIAL, ilog2(s->size) / 2);
>>> -	s->min_partial = max_t(unsigned long, MIN_PARTIAL, s->min_partial);
>>> -
>>> +	s->min_partial = 0;
>>>  	set_cpu_partial(s);
>>>  
>>>  #ifdef CONFIG_NUMA
>>>
>>>
>>> and booting with and without boot parameter slub_max_order=0?
>>
>> Test notes: I used Linus 6.1-rc5 as the base. That is the only thing I
>> changed in buildroot default config for the sipeed maix bit card, booting
>> with SD card. The test is: booting and run "cat /proc/vmstat" and register
>> the nr_free_pages value. I repeated the boot + cat 3 to 4 times for each case.
>>
>> Here are the results:
>>
>> 6.1-rc5, SLOB:
>>     - 623 free pages
>>     - 629 free pages
>>     - 629 free pages
>> 6.1-rc5, SLUB:
>>     - 448 free pages
>>     - 448 free pages
>>     - 429 free pages
>> 6.1-rc5, SLUB + slub_max_order=0:
>>     - Init error, shell prompt but no shell command working
>>     - Init error, no shell prompt
>>     - 508 free pages
>>     - Init error, shell prompt but no shell command working
>> 6.1-rc5, SLUB + patch:
>>     - Init error, shell prompt but no shell command working
>>     - 433 free pages
>>     - 448 free pages
>>     - 423 free pages
>> 6.1-rc5, SLUB + slub_max_order=0 + patch:
>>     - Init error, no shell prompt
>>     - Init error, shell prompt, 499 free pages
>>     - Init error, shell prompt but no shell command working
>>     - Init error, no shell prompt
>>
>> No changes for SLOB results, expected.
>>
>> For default SLUB, I did get all clean boots this time and could run the
>> cat command. But I do see shell fork failures if I keep running commands.
>>
>> For SLUB + slub_max_order=0, I only got one clean boot with 508 free
>> pages. Remaining runs failed to give a shell prompt or allow running cat
>> command. For the clean boot, I do see higher number of free pages.
>>
>> SLUB with the patch was nearly identical to SLUB without the patch.
>>
>> And SLUB+patch+slub_max_order=0 gave again a lot of errors/bad boot. I
>> could run the cat command only once, giving 499 free pages, so better than
>> regular SLUB. But it seems that the memory is more fragmented as
>> allocations fail more often.
>>
>> Hope this helps. Let me know if you want to test something else.
> 
> Could you please try this branch with CONFIG_SLUB_TINY=y?
> https://git.kernel.org/pub/scm/linux/kernel/git/vbabka/linux.git/log/?h=slub-tiny-v1r0
> 
> Seeing your results I didn't modify default slub_max_order by this new
> CONFIG (yet?) so maybe after trying the default, trying then also with
> manual slub_max_order=0 and slub_max_order=1 would be useful too. Otherwise
> it should be all changes to lower SLUB memory footprint. Hopefully it will
> be visible in the number of free pages. But if fragmentation is an issue, it
> might not be enough. BTW, during boot there should be a line "Built X
> zonelists, mobility grouping ..." can you grep for it and provide please, I
> wonder if mobility grouping ends up being off or on on that system.

I ran your branch with CONFIG_SLUB_TINY=y. Here are the results with 3-4
runs per config:

* tiny slub with default slub_max_order:
	- Clean boot, 579 free pages
	- Clean boot, 575 free pages
	- Clean boot, 579 free pages

* tiny slub with slub_max_order=0 as boot argument:
        - Init error, shell prompt but no shell command working
	- Init error, shell prompt, 592 free pages
	- Init error, shell prompt, 591 free pages
	- Init error, shell prompt, 591 free pages

* tiny slub with slub_max_order=1 as boot argument:
	- Clean boot, 601 free pages
	- Clean boot, 601 free pages
	- Clean boot, 591 free pages
	- Clean boot, 601 free pages

For all cases, mobility grouping was reported as off:

[    0.000000] Built 1 zonelists, mobility grouping off.  Total pages: 2020

So it looks like your tiny slub branch with slub_max_order=1 puts us
almost on par with slob and that slub_max_order=0 seems to be generating
more fragmentation leading to unreliable boot. I also tried
slub_max_order=2, which gives clean boot and around 582 free pages, almost
the same as the default.

With this branch applied, I have no issues with having slob deprecated :)
Thanks !


> 
> Thanks!
> 
>> Cheers.
>>
> 

-- 
Damien Le Moal
Western Digital Research

Re: Deprecating and removing SLOB

[Vlastimil Babka]

On 11/21/22 05:30, Damien Le Moal wrote:
> On 11/17/22 02:51, Vlastimil Babka wrote:
>> On 11/15/22 05:24, Damien Le Moal wrote:
>>> On 11/14/22 23:47, Hyeonggon Yoo wrote:
>>>> On Mon, Nov 14, 2022 at 08:35:31PM +0900, Damien Le Moal wrote:
>>>
>>> Test notes: I used Linus 6.1-rc5 as the base. That is the only thing I
>>> changed in buildroot default config for the sipeed maix bit card, booting
>>> with SD card. The test is: booting and run "cat /proc/vmstat" and register
>>> the nr_free_pages value. I repeated the boot + cat 3 to 4 times for each case.
>>>
>>> Here are the results:
>>>
>>> 6.1-rc5, SLOB:
>>>     - 623 free pages
>>>     - 629 free pages
>>>     - 629 free pages
>>> 6.1-rc5, SLUB:
>>>     - 448 free pages
>>>     - 448 free pages
>>>     - 429 free pages
>>> 6.1-rc5, SLUB + slub_max_order=0:
>>>     - Init error, shell prompt but no shell command working
>>>     - Init error, no shell prompt
>>>     - 508 free pages
>>>     - Init error, shell prompt but no shell command working
>>> 6.1-rc5, SLUB + patch:
>>>     - Init error, shell prompt but no shell command working
>>>     - 433 free pages
>>>     - 448 free pages
>>>     - 423 free pages
>>> 6.1-rc5, SLUB + slub_max_order=0 + patch:
>>>     - Init error, no shell prompt
>>>     - Init error, shell prompt, 499 free pages
>>>     - Init error, shell prompt but no shell command working
>>>     - Init error, no shell prompt
>>>
>>> No changes for SLOB results, expected.
>>>
>>> For default SLUB, I did get all clean boots this time and could run the
>>> cat command. But I do see shell fork failures if I keep running commands.
>>>
>>> For SLUB + slub_max_order=0, I only got one clean boot with 508 free
>>> pages. Remaining runs failed to give a shell prompt or allow running cat
>>> command. For the clean boot, I do see higher number of free pages.
>>>
>>> SLUB with the patch was nearly identical to SLUB without the patch.
>>>
>>> And SLUB+patch+slub_max_order=0 gave again a lot of errors/bad boot. I
>>> could run the cat command only once, giving 499 free pages, so better than
>>> regular SLUB. But it seems that the memory is more fragmented as
>>> allocations fail more often.
>>>
>>> Hope this helps. Let me know if you want to test something else.
>> 
>> Could you please try this branch with CONFIG_SLUB_TINY=y?
>> https://git.kernel.org/pub/scm/linux/kernel/git/vbabka/linux.git/log/?h=slub-tiny-v1r0
>> 
>> Seeing your results I didn't modify default slub_max_order by this new
>> CONFIG (yet?) so maybe after trying the default, trying then also with
>> manual slub_max_order=0 and slub_max_order=1 would be useful too. Otherwise
>> it should be all changes to lower SLUB memory footprint. Hopefully it will
>> be visible in the number of free pages. But if fragmentation is an issue, it
>> might not be enough. BTW, during boot there should be a line "Built X
>> zonelists, mobility grouping ..." can you grep for it and provide please, I
>> wonder if mobility grouping ends up being off or on on that system.
> 
> I ran your branch with CONFIG_SLUB_TINY=y. Here are the results with 3-4
> runs per config:
> 
> * tiny slub with default slub_max_order:
> 	- Clean boot, 579 free pages
> 	- Clean boot, 575 free pages
> 	- Clean boot, 579 free pages
> 
> * tiny slub with slub_max_order=0 as boot argument:
>         - Init error, shell prompt but no shell command working
> 	- Init error, shell prompt, 592 free pages
> 	- Init error, shell prompt, 591 free pages
> 	- Init error, shell prompt, 591 free pages
> 
> * tiny slub with slub_max_order=1 as boot argument:
> 	- Clean boot, 601 free pages
> 	- Clean boot, 601 free pages
> 	- Clean boot, 591 free pages
> 	- Clean boot, 601 free pages

Oh that's great result, better than I'd hope!
I'll change the default slub_max_order=1 with CONFIG_SLUB_TINY then.

> For all cases, mobility grouping was reported as off:
> 
> [    0.000000] Built 1 zonelists, mobility grouping off.  Total pages: 2020

Yeah, expected that would be the case, thanks for confirming.

> So it looks like your tiny slub branch with slub_max_order=1 puts us
> almost on par with slob and that slub_max_order=0 seems to be generating
> more fragmentation leading to unreliable boot. I also tried
> slub_max_order=2, which gives clean boot and around 582 free pages, almost
> the same as the default.
> 
> With this branch applied, I have no issues with having slob deprecated :)
> Thanks !

Great, thanks for the testing!

>> 
>> Thanks!
>> 
>>> Cheers.
>>>
>> 
> 

Re: Deprecating and removing SLOB

[Hyeonggon Yoo]

On Mon, Nov 14, 2022 at 10:36:31AM +0100, Vlastimil Babka wrote:
> On 11/14/22 06:48, Damien Le Moal wrote:
> > On 11/14/22 10:55, Damien Le Moal wrote:
> >> On 11/12/22 05:46, Conor Dooley wrote:
> >>> On Fri, Nov 11, 2022 at 11:33:30AM +0100, Vlastimil Babka wrote:
> >>>> 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/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
> >>>
> >>>>
> >>>> 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/riscv/configs/nommu_virt_defconfig:CONFIG_EXPERT=y
> >>>
> >>> I suppose there's not really a concern with the virt defconfig, but I
> >>> did check the output of `make nommu_k210_defconfig" and despite not
> >>> having expert it seems to end up CONFIG_SLOB=y in the generated .config.
> >>>
> >>> I do have a board with a k210 so I checked with s/SLOB/SLUB and it still
> >>> boots etc, but I have no workloads or w/e to run on it.
> >> 
> >> I sent a patch to change the k210 defconfig to using SLUB. However...
> 
> Thanks!
> 
> >> The current default config using SLOB gives about 630 free memory pages
> >> after boot (cat /proc/vmstat). Switching to SLUB, this is down to about
> >> 400 free memory pages (CONFIG_SLUB_CPU_PARTIAL is off).
> 
> Thanks for the testing! How much RAM does the system have btw? I found 8MB
> somewhere, is that correct?
> So 230 pages that's a ~920 kB difference. Last time we saw less  dramatic
> difference [1]. But that was looking at Slab pages, not free pages.

IIRC overhead of s->min_partial (between 5 and 10) was pretty big because SLUB
caches at most (s->min_partial) * (nr of caches) * (size of slab) bytes of
unused memory.

Passing slub_max_order=0 also may help a little bit.

> The extra overhead could be also in percpu allocations, code etc.

SLUB do not use large amount of percpu allocator I think, less than
30kB on such a small machine.

Maybe also it would help reducing code size to disable CONFIG_MEMCG and CONFIG_TRACING,
CONFIG_SLUB_DEBUG and CONFIG_SYSFS.

I started from tinyconfig and enabled only necessary configs when testing in [1]
(it's a bit laborious cuz pure tinyconfig does not even boot...).

> >> This is with a buildroot kernel 5.19 build including a shell and sd-card
> >> boot. With SLUB, I get clean boots and a shell prompt as expected. But I
> >> definitely see more errors with shell commands failing due to allocation
> >> failures for the shell process fork. So as far as the K210 is concerned,
> >> switching to SLUB is not ideal.
> >> 
> >> I would not want to hold on kernel mm improvements because of this toy
> >> k210 though, so I am not going to prevent SLOB deprecation. I just wish
> >> SLUB itself used less memory :)
> > 
> > Did further tests with kernel 6.0.1:
> > * SLOB: 630 free pages after boot, shell working (occasional shell fork
> > failure happen though)
> > * SLAB: getting memory allocation for order 7 failures on boot already
> > (init process). Shell barely working (high frequency of shell command fork
> > failures)
> > * SLUB: getting memory allocation for order 7 failures on boot. I do get a
> > shell prompt but cannot run any shell command that involves forking a new
> > process.
> > 
> > So if we want to keep the k210 support functional with a shell, we need
> > slob. If we reduce that board support to only one application started as
> > the init process, then I guess anything is OK.
> 
> In [1] it was possible to save some more memory with more tuning. Some of
> that required boot parameters and other code changes. In another reply [2] I
> considered adding something like SLUB_TINY to take care of all that, so
> looks like it would make sense to proceed with that.
> 
> [1]
> https://lore.kernel.org/all/Yg9xSWEaTZLA+hYt@ip-172-31-19-208.ap-northeast-1.compute.internal/
> [2] https://lore.kernel.org/all/eebc9dc8-6a45-c099-61da-230d06cb3157@suse.cz/

-- 
Thanks,
Hyeonggon