Re: [QUESTION] is SLAB considered legacy and deprecated?

[Hyeonggon Yoo]

Hello Vlastimil! I'm happy to discuss with you.
I hope this discussion to make us think about slab allocator.

On Fri, Oct 01, 2021 at 04:07:56PM +0200, Vlastimil Babka wrote:
> >> In some contexts it's still being preferred, AFAIK.
> > 
> > In what context is SLAB or SLUB is preferred?
> 
> I don't know the full answer. With our distro we have used SLAB, and
> switched to SLUB after verifying that there are no major regressions.
> Better debugging features were perhaps the major reason.
>

> > And what is the core reason that SLUB is used by default?
> 
> The usual reason in MM, nobody objected :)
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=a0acd82080768
>

What was the decision based on ? performance measurements or anything
else? 'Because nobody objected' is not a good reason to make a decision.

>>>> So there is a fundamental question coming into my mind:
>>>>     'is SLAB considered legacy and deprecated?'
>>>
>>> To some extend, but not yet in a sense where we would have a deadline to get
>>> rid of it.
>>>
>> What makes you to say 'To some extent'?
>> That's what I'm curious about :)

> "To some extent" because SLUB is default and if some new stuff was added
> that only worked with SLUB and not SLAB, there wouldn't be major
> objections expected.

You said new features are added to only SLUB and there are no
objections expected, But what makes you to do so?

You are not saying why. what you are saying is just only result.
What is the mind behind maintaining SLUB and neglecting SLAB?

is SLUB really next-generation slab allocator that can ultimately replace SLAB?
if so, why not just drop SLAB?
if not, why not maintain SLAB?

> >>> It seems there are little development on SLAB and people think that
> >>> SLAB is legacy and deprecated, so CONFIG_SLUB is used by default.
> >>>
> >>> But I think both has pros and cons for their own:
> >>> 	SLAB: more temporal locality (cache friendly)
> >>> 	but high usage of memory, and less spatial locality (TLB misses) than SLUB.
> >>>
> >>> 	SLUB: less temporal locality (less cache friendly) than SLAB
> >>> 	but more spatial locality (TLB hit), and low usage of memory
> >>> 	and good debugging feature.
> >>
> >> I'm not so sure about the usage of memory, SLUB can easily use more I
> >> believe. Instead of caching some arrays of objects it will have one or more
> >> private slabs per cpu, and the slabs are larger-order pages.
> >>
> > 
> > SLAB uses much memory than slab, when there are *lots* of NUMA nodes.
> > 	because kmem_cache_node exist per node and it keeps alien cache
> > 	(used for caching freeing object from remote node),
> > 	so it keeps MAX_NUMANODES ^ 2 of array_cache per slab.
> > 	that is why I said SLAB uses much memory than SLUB.
> 
> Maybe, theoretically. But SLUB has per-cpu partial lists caching whole
> slab pages, not just arrays of objects. Number of cpus will generally
> grow with number of NUMA nodes.
> 

Sorry, it was my mistake. I mean SLAB uses much memory than SLUB when
there are lots of NUMA nodes. in SLAB, there is alien_cache to batch
freeing objects from remote node. and alien cache has space complexity
of MAX_NUMNODES ^ 2. That's why I said SLAB uses much memory.

> > to quote Christoph Lameter's (who made SLUB and current maintainer) presentation in 2014:
> > 	See link [6] for this
> > 	p21: "SLAB queuing can get intensive memory usage going grows
> > 	exponentially by NUMA node"
> > 
> > But I'm not sure if SLAB or SLUB is good on UMA architecture.
> >

And that is one of reasons why Christoph made SLUB [8]

> >>> Why do people say SLAB is deprecated/legacy?
> >>
> >> Do they?
> >>
> > 
> > Yes I think they do.
> > 
> > One example is presentation of David Rientjes (one of maintainers) in 2011:
> > 	See link [7]
> > 	p5: "SLAB is deprecated, very little development"
> > 	p5: "Many distributions still ship with CONFIG_SLAB even
> > 		though it is not the kernel default"
> > 
> > Anyway, I wanted to discuss the current status of SLAB.
> > 
> > To me, it seems that people do not work on SLAB lately
> > and it seems some maintainers (David, Christoph) think
> > it's better to move from SLAB to SLUB. one of them is Christoph himself.
> > As he made SLUB because he don't agree on design of SLAB. [8]
> 
> Right.
> Here's the discussion from the last time SLAB removal was proposed and
> rejected, feel free to evaluate if the points there are still valid today:
> 
> https://lore.kernel.org/all/20190410024714.26607-1-tobin@xxxxxxxxxx/
>

I think the points are still valid because on some workloads SLAB works
better. especially when alloc/frees are intensive, SLUB tends to become
bottleneck.

If we can't drop SLAB, it should be at least maintained :(
But it has been neglected for a long time, which makes people not to
use SLAB. Nobody likes to use a subsystem that isn't maintained.

Anyway, I'm curious about share of SLAB and SLUB and on what situations
SLAB or SLUB is preferred. that information would help maintain both.

Thanks,
Hyeonggon

> > Thanks,
> > Hyeonggon.
> > 
> > Searching his name and sort by date
> > [1] https://lore.kernel.org/lkml/?q=Christoph+Lameter&o=10800
> > 
> > [GIT PULL] SLAB updates for 2.6.37-rc1 by Pekka Enberg
> > [2] https://lore.kernel.org/lkml/alpine.DEB.2.00.1010242005280.4447@tiger/#r
> > 
> > His work on lockless fastpath of slub (2011-02),
> > [3] https://lore.kernel.org/lkml/20110225173850.486326452@xxxxxxxxx/
> > 
> > His work on lockless fastpath of slub (2011-06)
> > [4] https://lore.kernel.org/lkml/20110601172543.437240675@xxxxxxxxx/
> > 
> > His work on per cpu partial lists
> > [5] https://lore.kernel.org/lkml/20110809211221.831975979@xxxxxxxxx/
> > 
> > Christoph's presentation on slab
> > [6] - https://events.static.linuxfound.org/sites/events/files/slides/slaballocators.pdf
> > 
> > David's presentation on slab
> > [7] - https://www.socallinuxexpo.org/scale9x-media/scalemedia/scale/scale9x-media/simple_cfp/presentations/16_30-DavidRientjes-Status_of_the_Linux_Slab_Allocators.pdf
> > 
> > [8] SLUB: The unqueued slab allocator V6
> > https://lwn.net/Articles/229096/
> > 
>