Re: [PATCH RT 00/02] SLOB optimizations

[Ingo Molnar <mingo@elte.hu>]

* Pekka J Enberg <penberg@cs.Helsinki.FI> wrote:

> > SLAB-bashing has become somewhat fashionable, but i really challenge 
> > everyone to improve the SLAB code first (to make it more modular, easier 
> > to read, etc.), before suggesting replacements.
> 
> I dropped working on the replacement because I wanted to do just that. 
> I sent my patch only because Matt and Steve talked about writing a 
> replacement and thought they would be interested to see it.
> 
> I am all for gradual improvements but after taking a stab at it, I 
> starting to think rewriting would be easier, simply because the slab 
> allocator has been clean-up resistant for so long.

i'd suggest to try harder, unless you think the _fundamentals_ of the 
SLAB allocator are wrong. (which you are entitled to believe, but we 
also have to admit that the SLAB has been around for many years, and 
works pretty well)

most of the ugliness in slab.c comes from:

1) debugging. There's no easy solutions here, but it could be improved. 

2) bootstrapping. Bootstrapping an allocator in a generic way is hard.
   E.g. what if cache_cache gets larger than 1 page?

3) cache-footprint tricks and lockless fastpath. SLAB does things all 
   the right way, even that ugly memmove is the right thing. Maybe it 
   could be cleaned up, but the fundamental complexity will likely 
   remain.

	Ingo