Date: Wed, 16 Aug 2006 10:32:59 +0200
From: Andi Kleen <ak@muc.de>
To: David Chinner <dgc@sgi.com>
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
Message-Id: <20060816103259.f87c167a.ak@muc.de>
In-Reply-To: <20060816081208.GL51703024@melbourne.sgi.com>
References: <20060816022238.13379.24081.sendpatchset@schroedinger.engr.sgi.com>
	<20060816081208.GL51703024@melbourne.sgi.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 861
Lines: 21


> > 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. Fragmentation mostly happens when objects
have very different live times. If you mix objects of different types
into the same slab then you might get more fragmentation.
kmalloc already has that problem but it probably shouldn't be added 
to other slabs too.

-Andi

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/