From: Christoph Lameter <cl@linux-foundation.org>
To: Pekka Enberg <penberg@cs.helsinki.fi>
Cc: Peter Zijlstra <peterz@infradead.org>,
David Rientjes <rientjes@google.com>,
Matt Mackall <mpm@selenic.com>,
paulmck@linux.vnet.ibm.com, linux-mm@kvack.org,
LKML <linux-kernel@vger.kernel.org>,
Nick Piggin <npiggin@suse.de>
Subject: Re: lockdep complaints in slab allocator
Date: Fri, 27 Nov 2009 11:22:36 -0600 (CST) [thread overview]
Message-ID: <alpine.DEB.2.00.0911271116100.20368@router.home> (raw)
In-Reply-To: <4B0CDBDE.8090307@cs.helsinki.fi>
On Wed, 25 Nov 2009, Pekka Enberg wrote:
> SLUB is good for NUMA, SLAB is pretty much a disaster with it's alien
> tentacles^Hcaches. AFAIK, SLQB hasn't received much NUMA attention so it's not
> obvious whether or not it will be able to perform as well as SLUB or not.
>
> The biggest problem with SLUB is that most of the people (excluding Christoph
> and myself) seem to think the design is unfixable for their favorite workload
> so they prefer to either stay with SLAB or work on SLQB.
The current design of each has its own strength and its weaknesses. A
queued design is not good for HPC and financial apps since it requires
periodic queue cleaning (therefore disturbing a latency critical
application path). Queue processing can go out of hand if there are
many different types of memory (SLAB in NUMA configurations). So a
queueless allocator design is good for some configurations. It is also
beneficial if the allocator must be frugal with memory allocations.
There is not much difference for most workloads in terms of memory
consumption between SLOB and SLUB.
> I really couldn't care less which allocator we end up with as long as it's not
> SLAB. I do think putting more performance tuning effort into SLUB would give
> best results because the allocator is pretty rock solid at this point. People
> seem underestimate the total effort needed to make a slab allocator good
> enough for the general public (which is why I think SLQB still has a long way
> to go).
There are still patches queued here for SLUB that depend on other per cpu
work to be merged in .33. These do not address the caching issues that
people focus on for networking and enterprise apps but they decrease the
minimum latency important for HPC and financial apps. The SLUB fastpath is
the lowest latency allocation path that exists.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2009-11-27 17:23 UTC|newest]
Thread overview: 61+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-11-18 18:12 Paul E. McKenney
2009-11-20 6:49 ` Pekka Enberg
2009-11-20 9:25 ` Peter Zijlstra
2009-11-20 10:38 ` Pekka Enberg
2009-11-20 10:52 ` Peter Zijlstra
2009-11-20 11:05 ` Pekka Enberg
2009-11-20 14:48 ` Paul E. McKenney
2009-11-20 15:17 ` Peter Zijlstra
2009-11-20 16:25 ` Paul E. McKenney
2009-11-20 15:09 ` Peter Zijlstra
2009-11-23 19:00 ` Pekka Enberg
2009-11-23 19:10 ` Matt Mackall
2009-11-23 19:13 ` Pekka Enberg
2009-11-24 16:33 ` Peter Zijlstra
2009-11-24 17:00 ` Paul E. McKenney
2009-11-24 17:12 ` Matt Mackall
2009-11-24 17:58 ` Paul E. McKenney
2009-11-24 18:14 ` Peter Zijlstra
2009-11-24 18:25 ` Paul E. McKenney
2009-11-24 18:31 ` Peter Zijlstra
2009-11-24 18:53 ` Christoph Lameter
2009-11-24 18:54 ` Paul E. McKenney
2009-11-24 19:23 ` Matt Mackall
2009-11-24 19:50 ` Paul E. McKenney
2009-11-24 20:46 ` Peter Zijlstra
2009-11-24 20:53 ` Matt Mackall
2009-11-24 21:01 ` Peter Zijlstra
2009-11-24 21:03 ` David Rientjes
2009-11-24 21:12 ` Peter Zijlstra
2009-11-24 21:19 ` Pekka Enberg
2009-11-24 21:22 ` David Rientjes
2009-11-24 21:35 ` Peter Zijlstra
2009-11-24 21:46 ` David Rientjes
2009-11-24 22:23 ` Paul E. McKenney
2009-11-25 7:12 ` Pekka Enberg
2009-11-25 7:25 ` Pekka Enberg
2009-11-27 17:22 ` Christoph Lameter [this message]
2009-11-24 21:48 ` Paul E. McKenney
2009-11-24 21:16 ` Pekka Enberg
2009-11-24 21:07 ` Pekka Enberg
2009-11-24 22:55 ` Matt Mackall
2009-11-25 21:59 ` David Rientjes
2009-11-25 23:06 ` Matt Mackall
2009-11-27 17:28 ` Christoph Lameter
2009-11-30 23:14 ` David Rientjes
2009-12-01 0:21 ` Matt Mackall
2009-12-01 22:41 ` David Rientjes
2009-12-01 16:47 ` Christoph Lameter
2009-11-27 17:26 ` Christoph Lameter
2009-11-23 19:30 ` Christoph Lameter
2009-11-23 19:43 ` Paul E. McKenney
2009-11-23 19:50 ` Pekka Enberg
2009-11-23 20:01 ` Pekka Enberg
2009-11-23 20:57 ` Paul E. McKenney
2009-11-23 21:01 ` Matt Mackall
2009-11-24 16:23 ` Paul E. McKenney
2009-11-24 20:59 ` Pekka Enberg
2009-11-24 21:26 ` Peter Zijlstra
2009-11-25 10:42 ` Pekka Enberg
2009-11-24 21:47 ` Paul E. McKenney
2009-11-30 16:18 ` Paul E. McKenney
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=alpine.DEB.2.00.0911271116100.20368@router.home \
--to=cl@linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mpm@selenic.com \
--cc=npiggin@suse.de \
--cc=paulmck@linux.vnet.ibm.com \
--cc=penberg@cs.helsinki.fi \
--cc=peterz@infradead.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox