Re: [patch 1/3] slob: rework freelist handling

Christoph Lameter
2007-05-23T19:59:05Z

On Wed, 23 May 2007, Matt Mackall wrote:

> 748K SLUB
> 1068K SLOB (old SLOB saves 320K)
> 1140K SLOB++ (Nick's improvements save an additional 72K for 392K total)
>
> (It'd be nice to have a SLAB number in there for completeness.)
>
> Nick's patches also make SLOB reasonably performant on larger machines
> (and can be a bit faster with a little tweaking). But it'll never be
> as fast as SLAB or SLUB - it has to walk lists. Similarly, I think
> it's basically impossible for a SLAB-like system that segregates
> objects of different sizes onto different pages to compete with a
> linked-list allocator on size. Especially now that Nick's reduced the
> kmalloc overhead to 2 bytes!
>
> So as long as there are machines where 100K or so makes a difference,
> there'll be a use for a SLOB-like allocator.

Hummm... We have not tested with my patch yet. May save another 200k.

And also the situation that Nick created is a bit artificial. One should
at least have half the memory available for user space I would think. If
there is a small difference after bootup then its not worth to keep SLOB
around. In particular since any real user space stuff will likely cause
fragmentation in SLOB which over the long hawl will be a problem vs.
SLA/UB.