Re: New dcache not using slab allocator?

Martin von Loewis (
4 Aug 1997 21:20:10 -0500

> > it's still buggy, so we fall back to kmalloc(). SIMP is even faster than
> > SLAB.
> But is it worth all the extra code space ?

I would not be so concerned with code space, but with the data space:
In 2.1.47+3, simp.o has 1248 bytes of code, compared to 6856 in slab.o.

However, if somebody allocates the first simp pool, it will consume
one page (4096 bytes) for the global data. I don't see why: the pools
could be dynamically allocated (e.g. using kmalloc), or statically
by each subsystem using a simp (i.e. you'd need as much memory as there
are simps). The spinlock probably still needs to be global, but that's
no problem.

Furthermore, allocating a single object from the simp consumes four
pages (16384 bytes). This is because the chunk size is four pages.
Is this a realistic size of inodes and dentries?

And why is this structor business a good thing? I would think that
code deallocating an object very well knows how to clear it before
releasing it; same for a freshly allocated object: the allocator usually
knows how to initialize it. Checking for function pointers all the time
seems like an unnecessary overhead.

I'm not sure it is a good idea to have two pool allocators in the
kernel. If they are both useful, one should be really light. Is somebody
measuring these things?

Just curious,