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,
Martin