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

Matt Mackall
2007-05-23T19:35:47Z

On Wed, May 23, 2007 at 10:07:33AM -0700, Christoph Lameter wrote:
> On Wed, 23 May 2007, Nick Piggin wrote:
>
> > Oh, and just out of interest, SLOB before my patches winds up with
> > 1068K free, so it is good to know the patches were able to save a bit
> > on this setup.
>
> Ahhh.. Its you who did the evil deed. By copying SLUB ideas SLOB became
> better than SLUB.

Uh, what? SLOB's memory usage was already better.

Quoting Nick:
> After booting and mounting /proc, SLOB has 1140K free, SLUB has 748K
> free.

So that's:

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.

--
Mathematics is the supreme nostalgia of our time.