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 14:22:34 +0000
From:   Hyeonggon Yoo <42.hyeyoo@...il.com>
To:     Vlastimil Babka <vbabka@...e.cz>
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 Mon, Oct 04, 2021 at 01:34:17PM +0200, Vlastimil Babka wrote:
> 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!
> 

Me too, Thanks for answering.

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

I can't find it in the list too.
Maybe it was not sent to list.

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

I got your point.
no need to take unnecessary maintenance cost.

Thanks,
Hyeonggon