Re: [patch 09/10] Remove the SLOB allocator for 2.6.23

[Nick Piggin <nickpiggin@yahoo.com.au>]

Pekka Enberg wrote:
> Hi Nick,
> 
> On 7/9/07, Nick Piggin <nickpiggin@yahoo.com.au> 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.