From: David Chinner <dgc@sgi.com>
To: Andi Kleen <ak@muc.de>
Cc: Christoph Lameter <clameter@sgi.com>,
mpm@selenic.com, Marcelo Tosatti <marcelo@kvack.org>,
linux-kernel@vger.kernel.org,
Nick Piggin <nickpiggin@yahoo.com.au>, Andi Kleen <ak@suse.de>,
Manfred Spraul <manfred@colorfullife.com>
Subject: Re: [MODSLAB 0/7] A modular slab allocator V1
Date: Wed, 16 Aug 2006 19:18:15 +1000 [thread overview]
Message-ID: <20060816091814.GM51703024@melbourne.sgi.com> (raw)
In-Reply-To: <20060816103259.f87c167a.ak@muc.de>
On Wed, Aug 16, 2006 at 10:32:59AM +0200, Andi Kleen wrote:
>
> > > 3. New slabs that are created can be merged into the kmalloc array
> > > if it is detected that they match. This decreases the number of caches
> > > and benefits cache use.
> >
> > While this will be good for reducing fragmentation,
>
> Will it? The theory behind a zone allocator like slab is that objects of the
> same type have similar livetimes.
True, but not all users of the slab caches are similar lifetime objects. e.g.
bufferheads, dentries, inodes, filps, radix tree nodes, etc all have effectively
random lifetimes. i'd say that most linux slab objects don't have that
property....
> Fragmentation mostly happens when objects
> have very different live times.
*nod*
Just look at how badly the inode and dentry slabs can fragment....
> If you mix objects of different types
> into the same slab then you might get more fragmentation.
Yes, but you don't tend to get the same worst case behaviour
that you get with single use slabs. With multiple use slabs, long
lifetime objects tend to accumulate on the same pages as different
objects come and go from the pages. IOWs, you waste less pages
in a fragmented multi-object cache that you do in N fragmented
single use caches.
> kmalloc already has that problem but it probably shouldn't be added
> to other slabs too.
I've never seen the kmalloc slabs show anywhere near the levels of
fragmentation I've seen from the inode and dentry slabs.....
Cheers,
Dave.
--
Dave Chinner
Principal Engineer
SGI Australian Software Group
next prev parent reply other threads:[~2006-08-16 9:19 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-08-16 2:22 Christoph Lameter
2006-08-16 2:22 ` [MODSLAB 1/7] Extract allocpercpu from Slab Christoph Lameter
2006-08-16 2:22 ` [MODSLAB 2/7] Allocator Framework and misc features Christoph Lameter
2006-08-16 2:22 ` [MODSLAB 3/7] A Kmalloc subsystem Christoph Lameter
2006-08-16 7:43 ` Andi Kleen
2006-08-17 0:24 ` Christoph Lameter
2006-08-17 5:19 ` Manfred Spraul
2006-08-17 11:42 ` Andi Kleen
2006-08-17 16:26 ` Christoph Lameter
2006-08-19 7:08 ` Manfred Spraul
2006-08-19 16:46 ` Christoph Lameter
2006-08-19 18:54 ` Manfred Spraul
2006-08-19 19:17 ` Christoph Lameter
2006-08-18 6:17 ` Christoph Lameter
2006-08-18 7:17 ` KAMEZAWA Hiroyuki
2006-08-18 16:58 ` Christoph Lameter
2006-08-18 18:19 ` KAMEZAWA Hiroyuki
2006-08-18 18:44 ` Christoph Lameter
2006-08-18 19:13 ` KAMEZAWA Hiroyuki
2006-08-18 19:19 ` Christoph Lameter
2006-08-16 2:22 ` [MODSLAB 4/7] Slabulator: Emulate the existing Slab Layer Christoph Lameter
2006-08-16 2:23 ` [MODSLAB 5/7] A slab allocator: SLABIFIER Christoph Lameter
2006-08-16 2:23 ` [MODSLAB 6/7] A slab allocator: NUMA Slab allocator Christoph Lameter
2006-08-16 2:23 ` [MODSLAB 7/7] A slab allocator: Page " Christoph Lameter
2006-08-16 7:52 ` [MODSLAB 0/7] A modular slab allocator V1 Andi Kleen
2006-08-16 8:41 ` Matt Mackall
2006-08-16 9:38 ` David Chinner
2006-08-16 15:08 ` Christoph Lameter
2006-08-16 15:05 ` Christoph Lameter
2006-08-16 8:12 ` David Chinner
2006-08-16 8:32 ` Andi Kleen
2006-08-16 9:18 ` David Chinner [this message]
2006-08-16 15:06 ` Christoph Lameter
2006-08-16 16:15 ` Manfred Spraul
2006-08-16 21:49 ` Christoph Lameter
2006-08-16 22:16 ` Christoph Lameter
2006-08-16 22:34 ` Christoph Lameter
2006-08-16 22:45 ` 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=20060816091814.GM51703024@melbourne.sgi.com \
--to=dgc@sgi.com \
--cc=ak@muc.de \
--cc=ak@suse.de \
--cc=clameter@sgi.com \
--cc=linux-kernel@vger.kernel.org \
--cc=manfred@colorfullife.com \
--cc=marcelo@kvack.org \
--cc=mpm@selenic.com \
--cc=nickpiggin@yahoo.com.au \
/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®