linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Michal Hocko <mhocko@kernel.org>
To: Christoph Lameter <cl@linux.com>
Cc: Andi Kleen <andi@firstfloor.org>,
	Joonsoo Kim <iamjoonsoo.kim@lge.com>,
	Aruna Ramakrishna <aruna.ramakrishna@oracle.com>,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org,
	Mike Kravetz <mike.kravetz@oracle.com>,
	Pekka Enberg <penberg@kernel.org>,
	David Rientjes <rientjes@google.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Mel Gorman <mgorman@suse.de>, Jiri Slaby <jslaby@suse.cz>
Subject: Re: what is the purpose of SLAB and SLUB
Date: Thu, 25 Aug 2016 09:32:07 +0200	[thread overview]
Message-ID: <20160825073207.GE4230@dhcp22.suse.cz> (raw)
In-Reply-To: <alpine.DEB.2.20.1608242302290.1837@east.gentwo.org>

On Wed 24-08-16 23:10:03, Christoph Lameter wrote:
> On Tue, 23 Aug 2016, Andi Kleen wrote:
> 
> > Why would you stop someone from working on SLAB if they want to?
> >
> > Forcibly enforcing a freeze on something can make sense if you're
> > in charge of a team to conserve resources, but in Linux the situation is
> > very different.
> 
> I agree and frankly having multiple allocators is something good.
> Features that are good in one are copied to the other and enhanced in the
> process. I think this has driven code development quite a bit.
> 
> Every allocator has a different basic approach to storage layout and
> synchronization which determines performance in various usage scenarios.
> The competition of seeing if the developer that is a fan of one can come
> up with a way to make performance better or storage use more effective in
> a situation where another shows better numbers is good.

I can completely see how having multiple allocators (schedulers etc...)
can be good as a playground. But how are users supposed to chose when
we do not help them with any documentation. Most benchmarks which are
referred to (e.g. SLUB doesn't work so well with the networking
workloads) might be really outdated and that just feeds the cargo cult.
Look, I am not suggesting removing SLAB (or SLUB) I am just really
looking to understand for their objectives and which users they target. 
Because as of now, most users are using whatever is the default (SLUB
for some and never documented reason) or what their distributions come
up with. This means that we have quite a lot of code which only few
people understand deeply. Some features which are added on top need much
more testing to cover both allocators or we are risking subtle
regressions.

> There may be more creative ways of coming up with new ways of laying out
> storage in the future and I would like to have the flexibility in the
> kernel to explore those if necessary with additional variations.

Flexibility is always good but there comes a maintenance burden. Both
should be weighed properly.

> The more common code we can isolate the easier it will become to just try
> out a new layout and a new form of serialization to see if it provides
> advantages.

Sure, but even after attempts to make some code common we are still at
$ wc -l mm/slab.c mm/slub.c 
	4479 mm/slab.c
	5727 mm/slub.c
	10206 total

quite a lot, don't you think?

-- 
Michal Hocko
SUSE Labs

  reply	other threads:[~2016-08-25  7:32 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     ` what is the purpose of SLAB and SLUB (was: Re: [PATCH v3] mm/slab: Improve performance of gathering slabinfo) stats Michal Hocko
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 [this message]
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:
  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=20160825073207.GE4230@dhcp22.suse.cz \
    --to=mhocko@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=andi@firstfloor.org \
    --cc=aruna.ramakrishna@oracle.com \
    --cc=cl@linux.com \
    --cc=iamjoonsoo.kim@lge.com \
    --cc=jslaby@suse.cz \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mgorman@suse.de \
    --cc=mike.kravetz@oracle.com \
    --cc=penberg@kernel.org \
    --cc=rientjes@google.com \
    --subject='Re: what is the purpose of SLAB and SLUB' \
    /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

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