Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Mon, 4 Oct 2021 14:22:34 +0000
From:   Hyeonggon Yoo <42.hyeyoo@gmail.com>
To:     Vlastimil Babka <vbabka@suse.cz>
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?
Message-ID: <20211004142234.GA3065@kvm.asia-northeast3-a.c.our-ratio-313919.internal>
References: <20210927090347.GA2533@linux.asia-northeast3-a.c.our-ratio-313919.internal>
 <8aa15f4b-71de-5283-5ebc-d8d1a323473d@suse.cz>
 <20210928111231.GA2596@linux.asia-northeast3-a.c.our-ratio-313919.internal>
 <b3c5bd9a-5fbc-8388-a4ab-6c20864dc7c6@suse.cz>
 <20211003055928.GA7643@linux.asia-northeast3-a.c.our-ratio-313919.internal>
 <8224ddae-88f5-63ab-c375-473462c50efe@suse.cz>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <8224ddae-88f5-63ab-c375-473462c50efe@suse.cz>
Precedence: bulk

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