From: Peter Zijlstra <a.p.zijlstra@chello.nl>
To: Andi Kleen <andi@firstfloor.org>
Cc: Christoph Lameter <clameter@sgi.com>,
Matt Mackall <mpm@selenic.com>, Ingo Molnar <mingo@elte.hu>,
Linus Torvalds <torvalds@linux-foundation.org>,
Pekka Enberg <penberg@cs.helsinki.fi>,
Hugh Dickins <hugh@veritas.com>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
William Lee Irwin III <wli@holomorphy.com>
Subject: Re: [PATCH] procfs: provide slub's /proc/slabinfo
Date: Fri, 04 Jan 2008 10:17:31 +0100 [thread overview]
Message-ID: <1199438251.7143.2.camel@twins> (raw)
In-Reply-To: <20080104024506.GA4665@one.firstfloor.org>
[-- Attachment #1: Type: text/plain, Size: 1075 bytes --]
On Fri, 2008-01-04 at 03:45 +0100, Andi Kleen wrote:
> > I still have trouble to see that SLOB still has much to offer. An embedded
> > allocator that in many cases has more allocation overhead than the default
> > one? Ok you still have advantages if allocations are rounded up to the
> > next power of two for a kmalloc and because of the combining of different
> > types of allocations in a single slab if there are an overall small number
> > of allocations. If one would create a custom slab for the worst problems
> > there then this may also go away.
>
> I suspect it would be a good idea anyways to reevaluate the power of two
> slabs. Perhaps a better distribution can be found based on some profiling?
> I did profile kmalloc using a systemtap script some time ago but don't
> remember the results exactly, but iirc it looked like it could be improved.
I remember wli trying to work out a series that had minimal
fragmentation. IIRC he was mixing a fibonaci series with the power of
two series.
Bill, do you remember getting anywhere?
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
next prev parent reply other threads:[~2008-01-04 9:17 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 [this message]
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
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=1199438251.7143.2.camel@twins \
--to=a.p.zijlstra@chello.nl \
--cc=andi@firstfloor.org \
--cc=clameter@sgi.com \
--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=wli@holomorphy.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