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 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 13:34:17 +0200
From:   Vlastimil Babka <vbabka@...e.cz>
To:     Hyeonggon Yoo <42.hyeyoo@...il.com>
Cc:     linux-mm@...ck.org, Christoph Lameter <cl@...ux.com>,
        Pekka Enberg <penberg@...nel.org>,
        David Rientjes <rientjes@...gle.com>,
        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 10/3/21 07:59, Hyeonggon Yoo wrote:
> Hello Vlastimil! I'm happy to discuss with you.
> I hope this discussion to make us think about slab allocator.

Yeah, it's useful, thanks for asking!

> 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

I haven't been around back then, so don't know. Also tried to find this
particular patch (and possible replies) in the linux-mm lore archive,
and didn't succeed. Might have been event sent off-list by mistake.

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

David explained it well. I'll add it's a question of motivation, people
generally add features to the subsystem they prefer, and most prefer
SLUB these days, and in that case we don't require the same feature to
be added to SLAB (or even SLOB) as well. But if someone wants to, we
also don't stop them - but to some extent. If someone suddenly came up
with "SLUB has this nice debugging and SLAB not, so I will reimplement
it there" we would be questioning hard if the code churn is really needed.