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

lists.openwall.net		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 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:   Sun, 3 Oct 2021 18:25:29 -0700 (PDT)
From:   David Rientjes <rientjes@...gle.com>
To:     Hyeonggon Yoo <42.hyeyoo@...il.com>
cc:     Vlastimil Babka <vbabka@...e.cz>, linux-mm@...ck.org,
        Christoph Lameter <cl@...ux.com>,
        Pekka Enberg <penberg@...nel.org>,
        Joonsoo Kim <iamjoonsoo.kim@....com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        linux-kernel@...r.kernel.org
Subject: Re: [QUESTION] is SLAB considered legacy and deprecated?

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.

I would disagree that SLAB isn't currently maintained, I think it's 
actively maintained.  Google actually uses it for its production kernel 
although we're investigating the performance results that we can obtain 
from SLUB not that we have per-object memcg accounting.  There have been 
workloads, as you mention, that perform better with SLAB even though SLUB 
can make up for some of its degradation by throwing more memory at the 
problem (like per-cpu partial slabs).

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.