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
