Re: [PATCH 0/1] mm: Remove the SLAB allocator

[Michal Hocko]

On Wed 10-04-19 18:16:18, Tobin C. Harding wrote:
> On Wed, Apr 10, 2019 at 10:02:36AM +0200, Vlastimil Babka wrote:
> > On 4/10/19 4:47 AM, Tobin C. Harding wrote:
> > > Recently a 2 year old bug was found in the SLAB allocator that crashes
> > > the kernel.  This seems to imply that not that many people are using the
> > > SLAB allocator.
> > 
> > AFAIK that bug required CONFIG_DEBUG_SLAB_LEAK, not just SLAB. That
> > seems to imply not that many people are using SLAB when debugging and
> > yeah, SLUB has better debugging support. But I wouldn't dare to make the
> > broader implication :)
> 
> Point noted.
> 
> > > Currently we have 3 slab allocators.  Two is company three is a crowd -
> > > let's get rid of one. 
> > > 
> > >  - The SLUB allocator has been the default since 2.6.23
> > 
> > Yeah, with a sophisticated reasoning :)
> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=a0acd820807680d2ccc4ef3448387fcdbf152c73
> > 
> > >  - The SLOB allocator is kinda sexy.  Its only 664 LOC, the general
> > >    design is outlined in KnR, and there is an optimisation taken from
> > >    Knuth - say no more.
> > > 
> > > If you are using the SLAB allocator please speak now or forever hold your peace ...
> > 
> > FWIW, our enterprise kernel use it (latest is 4.12 based), and openSUSE
> > kernels as well (with openSUSE Tumbleweed that includes latest
> > kernel.org stables). AFAIK we don't enable SLAB_DEBUG even in general
> > debug kernel flavours as it's just too slow.
> 
> Ok, so that probably already kills this.  Thanks for the response.  No
> flaming, no swearing, man! and they said LKML was a harsh environment ...
> 
> > IIRC last time Mel evaluated switching to SLUB, it wasn't a clear
> > winner, but I'll just CC him for details :)
> 
> Probably don't need to take up too much of Mel's time, if we have one
> user in production we have to keep it, right.

Well, I wouldn't be opposed to dropping SLAB. Especially when this is
not a longterm stable kmalloc implementation anymore. It turned out that
people want to push features from SLUB back to SLAB and then we are just
having two featurefull allocators and double the maintenance cost.

So as long as the performance gap is no longer there and the last data
from Mel (I am sorry but I cannot find a link handy) suggests that there
is no overall winner in benchmarks then why to keep them both?

That being said, if somebody is willing to go and benchmark both
allocators to confirm Mel's observations and current users of SLAB
can confirm their workloads do not regress either then let's just drop
it.

Please please have it more rigorous then what happened when SLUB was
forced to become a default
-- 
Michal Hocko
SUSE Labs