All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vlastimil Babka <vbabka@suse.cz>
To: Hyeonggon Yoo <42.hyeyoo@gmail.com>
Cc: linux-mm@kvack.org, Christoph Lameter <cl@linux.com>,
	Pekka Enberg <penberg@kernel.org>,
	David Rientjes <rientjes@google.com>,
	Joonsoo Kim <iamjoonsoo.kim@lge.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	linux-kernel@vger.kernel.org
Subject: Re: [QUESTION] is SLAB considered legacy and deprecated?
Date: Mon, 4 Oct 2021 13:34:17 +0200	[thread overview]
Message-ID: <8224ddae-88f5-63ab-c375-473462c50efe@suse.cz> (raw)
In-Reply-To: <20211003055928.GA7643@linux.asia-northeast3-a.c.our-ratio-313919.internal>

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.


  parent reply	other threads:[~2021-10-04 11:34 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-27  9:03 [QUESTION] is SLAB considered legacy and deprecated? Hyeonggon Yoo
2021-09-27 17:03 ` Vlastimil Babka
2021-09-28 11:12   ` Hyeonggon Yoo
2021-09-29 10:50     ` Hyeonggon Yoo
2021-10-01 14:07     ` Vlastimil Babka
2021-10-03  5:59       ` Hyeonggon Yoo
2021-10-04  1:25         ` David Rientjes
2021-10-04  1:25           ` David Rientjes
2021-10-04  6:01           ` Hyeonggon Yoo
2021-10-04 11:39             ` Vlastimil Babka
2021-10-05 13:31               ` Hyeonggon Yoo
2021-10-04 11:34         ` Vlastimil Babka [this message]
2021-10-04 14:22           ` Hyeonggon Yoo
2021-10-01  0:39   ` Queueing is outside of SLUB nowdays Hyeonggon Yoo
2021-10-04 14:56     ` Christoph Lameter
2021-10-04 14:56       ` Christoph Lameter
2021-10-05  8:19       ` Vlastimil Babka
2021-10-05 14:16         ` Hyeonggon Yoo

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=8224ddae-88f5-63ab-c375-473462c50efe@suse.cz \
    --to=vbabka@suse.cz \
    --cc=42.hyeyoo@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=cl@linux.com \
    --cc=iamjoonsoo.kim@lge.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=penberg@kernel.org \
    --cc=rientjes@google.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.