Re: [patch 09/10] Remove the SLOB allocator for 2.6.23
From: Nick Piggin
Date: Mon Jul 09 2007 - 07:17:18 EST
Pekka Enberg wrote:
Hi Nick,
On 7/9/07, Nick Piggin <nickpiggin@xxxxxxxxxxxx> wrote:
SLOB contains several significant O(1) and also O(n) memory savings that
are so far impossible-by-design for SLUB. They are: slab external
fragmentation is significantly reduced; kmalloc internal fragmentation is
significantly reduced; order of magnitude smaller kmem_cache data type;
order of magnitude less code...
I assume with "slab external fragmentation" you mean allocating a
whole page for a slab when there are not enough objects to fill the
whole thing thus wasting memory?
Yep. Without really analysing it, I guess SLOB's savings here are
O(1) over SLUB and will relatively diminish as the machine size gets
larger, however with the number of slabs even a small kernel creates,
this is likely to be significant on small memory systems.
We could try to combat that by
packing multiple variable-sized slabs within a single page. Also,
Yeah, that could help.
adding some non-power-of-two kmalloc caches might help with internal
fragmentation.
That too, although of course it will work against the external
fragmentation problem. This is more of an O(n) problem and may not
be responsible for as much waste as the first issue on small memory
machines (I haven't done detailed profiling so I don't know).
In any case, SLUB needs some serious tuning for smaller machines
before we can get rid of SLOB.
I would always be happy to see the default allocator become more
space efficient... I think it would be most productive to get
detailed profiles of exactly where the memory is being wasted on
small mem= boots. Although I don't think matching SLOB would be
an easy task at all.
--
SUSE Labs, Novell Inc.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/