archive mirror
 help / color / mirror / Atom feed
From: Michal Hocko <>
To: Joonsoo Kim <>
Cc: Aruna Ramakrishna <>,,,
	Mike Kravetz <>,
	Christoph Lameter <>,
	Pekka Enberg <>,
	David Rientjes <>,
	Andrew Morton <>,
	Mel Gorman <>, Jiri Slaby <>
Subject: what is the purpose of SLAB and SLUB (was: Re: [PATCH v3] mm/slab: Improve performance of gathering slabinfo) stats
Date: Tue, 23 Aug 2016 17:38:08 +0200	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <20160823021303.GB17039@js1304-P5Q-DELUXE>

On Tue 23-08-16 11:13:03, Joonsoo Kim wrote:
> On Thu, Aug 18, 2016 at 01:52:19PM +0200, Michal Hocko wrote:
> > I am not opposing the patch (to be honest it is quite neat) but this
> > is buggering me for quite some time. Sorry for hijacking this email
> > thread but I couldn't resist. Why are we trying to optimize SLAB and
> > slowly converge it to SLUB feature-wise. I always thought that SLAB
> > should remain stable and time challenged solution which works reasonably
> > well for many/most workloads, while SLUB is an optimized implementation
> > which experiment with slightly different concepts that might boost the
> > performance considerably but might also surprise from time to time. If
> > this is not the case then why do we have both of them in the kernel. It
> > is a lot of code and some features need tweaking both while only one
> > gets testing coverage. So this is mainly a question for maintainers. Why
> > do we maintain both and what is the purpose of them.
> I don't know full history about it since I joined kernel communitiy
> recently(?). Christoph would be a better candidate for this topic.
> Anyway,
> SLAB if SLUB beats SLAB completely. But, there are fundamental
> differences in implementation detail so they cannot beat each other
> for all the workloads. It is similar with filesystem case that various
> filesystems exist for it's own workload.

Do we have any documentation/study about which particular workloads
benefit from which allocator? It seems that most users will use whatever
the default or what their distribution uses. E.g. SLES kernel use SLAB
because this is what we used to have for ages and there was no strong
reason to change that default. From such a perspective having a stable
allocator with minimum changes - just bug fixes - makes a lot of sense.
I remember Mel doing some benchmarks when "why opensuse kernels do not
use the default SLUB allocator" came the last time and he didn't see any
large winner there
This set of workloads is of course not comprehensive to rule one or
other but I am wondering whether there are still any pathological
workloads where we really want to keep SLAB or add new features to it.

> Then, second plan was started. It is commonizing the code as much
> as possible to develope new feature and maintain the code easily. The
> code goes this direction, although it is slow. If it is achieved, we
> don't need to worry about maintanance overhead.

I fully agree, commonizing the code base makes perfect sense. If a
feature can be made independent on the underlying implementation then I
am all for adding it but AFAIR kmemcg or kmemleak both need to touch
quite deep internals and that brings risk for introducing new bugs which
would be SL[AU]B specific. I remember Jiri Slaby was fighting a kmemlead
false positives recently with SLAB which were not present in SLUB for

> Anyway, we cannot remove one without regression so we don't remove one
> until now. In this case, there is no point to stop improving one.

I can completely see the reason to not drop SLAB (and I am not suggesting
that) but I would expect that SLAB would be more in a feature freeze
state. Or if both of them need to evolve then at least describe which
workloads pathologically benefit/suffer from one or the other.

Michal Hocko

  reply	other threads:[~2016-08-23 15:38 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-08-17 18:20 [PATCH v3] mm/slab: Improve performance of gathering slabinfo stats Aruna Ramakrishna
2016-08-17 19:03 ` Eric Dumazet
2016-08-17 19:25   ` Aruna Ramakrishna
2016-08-18 11:52 ` Michal Hocko
2016-08-19  5:47   ` aruna.ramakrishna
2016-08-23  2:13   ` Joonsoo Kim
2016-08-23 15:38     ` Michal Hocko [this message]
2016-08-23 15:54       ` what is the purpose of SLAB and SLUB Andi Kleen
2016-08-25  4:10         ` Christoph Lameter
2016-08-25  7:32           ` Michal Hocko
2016-08-25 19:49             ` Christoph Lameter
2016-08-24  1:15       ` what is the purpose of SLAB and SLUB (was: Re: [PATCH v3] mm/slab: Improve performance of gathering slabinfo) stats Joonsoo Kim
2016-08-24  8:05         ` Michal Hocko
2016-08-24  8:20       ` Mel Gorman
2016-08-25  4:01         ` Christoph Lameter
2016-08-25 10:07           ` Mel Gorman
2016-08-25 19:55             ` Christoph Lameter
2016-08-26 20:47               ` what is the purpose of SLAB and SLUB Andi Kleen
2016-08-29 13:44                 ` Michal Hocko
2016-08-29 14:49                   ` Christoph Lameter
2016-08-30  9:39               ` what is the purpose of SLAB and SLUB (was: Re: [PATCH v3] mm/slab: Improve performance of gathering slabinfo) stats Mel Gorman
2016-08-30 19:32                 ` Christoph Lameter

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:

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

  git send-email \ \ \ \ \ \ \ \ \ \ \ \ \ \
    --subject='what is the purpose of SLAB and SLUB (was: Re: [PATCH v3] mm/slab: Improve performance of gathering slabinfo) stats' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).