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

Nick Piggin
2007-05-24T03:39:25Z

On Wed, May 23, 2007 at 12:59:05PM -0700, Christoph Lameter wrote:
> 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.

Saved 12K. Shuld it have been more? I only applied the last patch you
sent (plus the initial SLUB_DEBUG fix).

> 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.

Admittedly, I am not involved with any such tiny Linux projects, however
why should half of memory be available to userspace? What about a router
or firewall that basically does all work in kernel?

I think a really stripped down system can boot in 2MB of RAM these days,
so after the kernel actually boots, a few K probably == a few % of
remaining available memory.