Re: [MODSLAB 0/7] A modular slab allocator V1

[David Chinner <dgc@sgi.com>]

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
-
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/