Re: Deprecating and removing SLOB

[Christophe Leroy]

Le 08/11/2022 à 16:55, Vlastimil Babka a écrit :
> 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.

Well, the only one that supports PREEMPT_RT is SLUB as far as I can see 
in mm/Kconfig, so I guess both SLOB and SLAB will go away ?

> 
> 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 still have devices (powerpc) with only 32MB today and for the next ten 
years at least. But they have been using SLUB.

> 
> - 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?

Mark them as dependent on CONFIG_BROKEN ?

Christophe

> 
> 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@xxxxxxxxxxxxxxxxxxxxxxxxxxx-ratio-313919.internal/#t
> [3] 
> https://lore.kernel.org/all/20210930044202.GP2361455@xxxxxxxxxxxxxxxxxxx/
> 
>