From: Matt Mackall <mpm@selenic.com>
To: Andi Kleen <andi@firstfloor.org>
Cc: Christoph Lameter <clameter@sgi.com>, Ingo Molnar <mingo@elte.hu>,
Linus Torvalds <torvalds@linux-foundation.org>,
Pekka Enberg <penberg@cs.helsinki.fi>,
Hugh Dickins <hugh@veritas.com>,
Peter Zijlstra <a.p.zijlstra@chello.nl>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] procfs: provide slub's /proc/slabinfo
Date: Thu, 03 Jan 2008 22:34:44 -0600 [thread overview]
Message-ID: <1199421285.4608.95.camel@cinder.waste.org> (raw)
In-Reply-To: <20080104024506.GA4665@one.firstfloor.org>
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.
We can roughly group kmalloced objects into two classes:
a) intrinsically variable-sized (strings, etc.)
b) fixed-sized objects that nonetheless don't have their own caches
For (a), we can expect the size distribution to be approximately a
scale-invariant power distribution. So buckets of the form n**x make a
fair amount of sense. We might consider n less than 2 though.
For objects of type (b) that occur in significant numbers, well, we
might just want to add more caches. SLUB's merging of same-sized caches
will reduce the pain here.
> A long time ago i also had some code to let the network stack give hints
> about its MMUs to slab to create fitting slabs for packets. But that
> was never really pushed forward because it turned out it didn't help
> much for the most common 1.5K MTU -- always only two packets fit into
> a page.
Yes, that and task_struct kinda make you want to cry. Large-order
SLAB/SLUB/SLOB would go a long way to fix that, but has its own problems
of course.
One could imagine restructuring things so that the buddy allocator only
extended down to 64k or so and below that, gfp and friends called
through SLAB/SLUB/SLOB.
--
Mathematics is the supreme nostalgia of our time.
next prev parent reply other threads:[~2008-01-04 4:36 UTC|newest]
Thread overview: 69+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-01-02 18:43 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 [this message]
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
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=1199421285.4608.95.camel@cinder.waste.org \
--to=mpm@selenic.com \
--cc=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=penberg@cs.helsinki.fi \
--cc=torvalds@linux-foundation.org \
/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
all inboxes | Powered by JetHome®