From: Christoph Lameter <cl@linux-foundation.org>
To: Andi Kleen <andi@firstfloor.org>
Cc: Matt Mackall <mpm@selenic.com>,
Linus Torvalds <torvalds@linux-foundation.org>,
Pekka J Enberg <penberg@cs.helsinki.fi>,
Christoph Lameter <clameter@sgi.com>, Ingo Molnar <mingo@elte.hu>,
Hugh Dickins <hugh@veritas.com>,
Peter Zijlstra <a.p.zijlstra@chello.nl>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
vegard.nossum@gmail.com, hannes@saeurebad.de
Subject: Re: [RFC PATCH] greatly reduce SLOB external fragmentation
Date: Thu, 31 Jul 2008 10:25:45 -0500 [thread overview]
Message-ID: <4891D979.6090802@linux-foundation.org> (raw)
In-Reply-To: <20080731141134.GP23938@one.firstfloor.org>
Andi Kleen wrote:
>> Finally getting rid of SLAB is a much trickier proposition because SLUB
>> still loses in a few important corner cases.
>
> The big issue is that we haven't really made much progress on at least
> some of these test cases (like the database benchmarks) for quite some
> time (and that wasn't for a lack of trying) :-/ Might be a fundamental
> problem.
It would be good to have more of these benchmark regressions than just TPC which requires a database setup etc etc. Preferably something that is easily runnable by everyone.
There is a fundamental difference in how frees are handled. Slub is queueless so it must use an atomic operation on the page struct of the slab that we free to (in the case that the freeing does not occur to the current cpu slab) to serialize access.
SLAB can avoid that by just stuffing the pointer to the object to be freed into a per cpu queue. Then later the queue is processed and the objects are merged into the slabs. But the later workqueue processing then causes run time variabilities which impact network performance and cause latencies. And the queuing only works in the SMP case. In the NUMA case we need to first check the locality of the object and then stuff it into alien queues (if its not local node). Then we need to expire the alien queues at some point. We have these alien queues per node which means they require locks and we have NODES * CPUS of them.
next prev parent reply other threads:[~2008-07-31 15:27 UTC|newest]
Thread overview: 69+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-01-02 18:43 [PATCH] procfs: provide slub's /proc/slabinfo Hugh Dickins
2008-01-02 18:53 ` Christoph Lameter
2008-01-02 19:09 ` Pekka Enberg
2008-01-02 19:35 ` Linus Torvalds
2008-01-02 19:45 ` Linus Torvalds
2008-01-02 19:49 ` Pekka Enberg
2008-01-02 22:50 ` Matt Mackall
2008-01-03 8:52 ` Ingo Molnar
2008-01-03 16:46 ` Matt Mackall
2008-01-04 2:21 ` Christoph Lameter
2008-01-04 2:45 ` Andi Kleen
2008-01-04 4:34 ` Matt Mackall
2008-01-04 9:17 ` Peter Zijlstra
2008-01-04 20:37 ` Christoph Lameter
2008-01-04 4:11 ` Matt Mackall
2008-01-04 20:34 ` Christoph Lameter
2008-01-04 20:55 ` Matt Mackall
2008-01-04 21:36 ` Christoph Lameter
2008-01-04 22:30 ` Matt Mackall
2008-01-05 20:16 ` Christoph Lameter
2008-01-05 16:21 ` Pekka J Enberg
2008-01-05 17:14 ` Andi Kleen
2008-01-05 20:05 ` Christoph Lameter
2008-01-07 20:12 ` Pekka J Enberg
2008-01-06 17:51 ` Matt Mackall
2008-01-07 18:06 ` Pekka J Enberg
2008-01-07 19:03 ` Matt Mackall
2008-01-07 19:53 ` Pekka J Enberg
2008-01-07 20:44 ` Pekka J Enberg
2008-01-10 10:04 ` Pekka J Enberg
2008-01-09 19:15 ` [RFC PATCH] greatly reduce SLOB external fragmentation Matt Mackall
2008-01-09 22:43 ` Pekka J Enberg
2008-01-09 22:59 ` Matt Mackall
2008-01-10 10:02 ` Pekka J Enberg
2008-01-10 10:54 ` Pekka J Enberg
2008-01-10 15:44 ` Matt Mackall
2008-01-10 16:13 ` Linus Torvalds
2008-01-10 17:49 ` Matt Mackall
2008-01-10 18:28 ` Linus Torvalds
2008-01-10 18:42 ` Matt Mackall
2008-01-10 19:24 ` Christoph Lameter
2008-01-10 19:44 ` Matt Mackall
2008-01-10 19:51 ` Christoph Lameter
2008-01-10 19:41 ` Linus Torvalds
2008-01-10 19:46 ` Christoph Lameter
2008-01-10 19:53 ` Andi Kleen
2008-01-10 19:52 ` Christoph Lameter
2008-01-10 19:16 ` Christoph Lameter
2008-01-10 19:23 ` Matt Mackall
2008-01-10 19:31 ` Christoph Lameter
2008-01-10 21:25 ` Jörn Engel
2008-01-10 18:13 ` Andi Kleen
2008-07-30 21:51 ` Pekka J Enberg
2008-07-30 22:00 ` Linus Torvalds
2008-07-30 22:22 ` Pekka Enberg
2008-07-30 22:35 ` Linus Torvalds
2008-07-31 0:42 ` malc
2008-07-31 1:03 ` Matt Mackall
2008-07-31 1:09 ` Matt Mackall
2008-07-31 14:11 ` Andi Kleen
2008-07-31 15:25 ` Christoph Lameter [this message]
2008-07-31 16:03 ` Andi Kleen
2008-07-31 16:05 ` Christoph Lameter
2008-07-31 14:26 ` Christoph Lameter
2008-07-31 15:38 ` Matt Mackall
2008-07-31 15:42 ` Christoph Lameter
2008-01-10 2:46 ` Matt Mackall
2008-01-10 10:03 ` Pekka J Enberg
2008-01-03 20:31 ` [PATCH] procfs: provide slub's /proc/slabinfo 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=4891D979.6090802@linux-foundation.org \
--to=cl@linux-foundation.org \
--cc=a.p.zijlstra@chello.nl \
--cc=andi@firstfloor.org \
--cc=clameter@sgi.com \
--cc=hannes@saeurebad.de \
--cc=hugh@veritas.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=mpm@selenic.com \
--cc=penberg@cs.helsinki.fi \
--cc=torvalds@linux-foundation.org \
--cc=vegard.nossum@gmail.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