lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Mon, 4 Oct 2021 06:01:09 +0000
From:   Hyeonggon Yoo <>
To:     David Rientjes <>
Cc:     Vlastimil Babka <>,,
        Christoph Lameter <>,
        Pekka Enberg <>,
        Joonsoo Kim <>,
        Andrew Morton <>,
Subject: Re: [QUESTION] is SLAB considered legacy and deprecated?

On Sun, Oct 03, 2021 at 06:25:29PM -0700, David Rientjes wrote:
> On Sun, 3 Oct 2021, Hyeonggon Yoo wrote:
> > 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 for raising this, the discussion is always useful.  Both allocators 
> have their pros and cons.

Thanks for kind words, I was curious and wanted to help improve

> I would disagree that SLAB isn't currently maintained, I think it's 
> actively maintained.

I thought it was not actively maintained because most of patches were
fixups and cleanups for years and as Vlastimil said, new features are
only added to SLUB. development was focused on SLUB.

> I think the general guidance is that changes for both allocators can still
> be merged upstream if they show a significant win (improved performnace, 
> maintaining performance while reducing memory footprint, code hygiene, 
> etc) and there's no specific policy that we cannot make changes to 
> mm/slab.c.


I see things to improve in SLAB and want to improve it.
I will appreciate if you review them.


Powered by blists - more mailing lists