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

Nick Piggin
2007-05-23T03:06:37Z

On Tue, May 22, 2007 at 12:18:58PM -0700, Christoph Lameter wrote:
> On Tue, 22 May 2007, Matt Mackall wrote:
>
> > On Tue, May 22, 2007 at 09:39:10AM +0200, Nick Piggin wrote:
> > > Here are some patches I have been working on for SLOB, which makes
> > > it significantly faster, and also using less dynamic memory... at
> > > the cost of being slightly larger static footprint and more complex
> > > code.
> > >
> > > Matt was happy for the first 2 to go into -mm (and hasn't seen patch 3 yet).
> >
> > These all look good, thanks Nick!
> >
> > Acked-by: Matt Mackall <mpm@selenic.com>
>
> New SLUB inspired life for SLOB. I hope someone else tests this?

I'm sure there are people using SLOB, not sure if any of them test the
-mm tree, though. I am planning to get some size comparisons with other
allocators, which shouldn't take long (although I wouldn't know what a
representative tiny setup would look like).

> Are there any numbers / tests that give a continued reason for the
> existence of SLOB? I.e. show some memory usage on a real system that is
> actually lower than SLAB/SLUB? Or are there any confirmed platforms where
> SLOB is needed?

The only real numbers I have off-hand are these

$ size mm/slob.o
text data bss dec hex filename
4160 792 8 4960 1360 mm/slob.o
$ size mm/slub.o
text data bss dec hex filename
11728 6468 176 18372 47c4 mm/slub.o

I'll see if I can get some basic dynamic memory numbers soon. The problem
is that slub oopses on boot on the powerpc platform I'm testing on...