Re: [RFC] Simple Slab: A slab allocator with minimal meta information

[Andi Kleen <ak@suse.de>]

linux@horizon.com writes:

[this time without typo in cc, sorry if you get it twice]

> Um, with all this discussion of keeping caches hot, people do remember
> that FIFO handling of free blocks *greatly* reduces fragmentation, right?
> 
> That's an observation from malloc implementations that support merging
> of any two adjacent blocks, but at least some of it should apply to slab
> pages that require multple adjacent free objects to be returned to the
> free-page pool.

Interesting observation.

slab is a zone allocator and stores objects of the same type
into zones. The theory behind that is that normally that objects of the same
type have similar livetimes and that should in theory avoid
many fragmentation problems.

However some caches like dcache/inode cache don't seem to follow
that, and kmalloc which mixes all kinds of objects into the same
caches especially doesn't.

> Especially in a memory-constrained embedded environment, I'd think
> space-efficiency would be at least as important as time.

For memory-constrained environments there is already the optional 
specialized "slob" allocator.

That said even big systems have problems with fragmentation.

It is good that the basic assumptions behind slabs are being
revisited now. I suspect some of them might be obsolete.

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