As someone who *isn't* the implementor, let me second Mark's shock.
The slab allocator's special features are grossly underused in the
current kernel. Implementing "kmalloc" on top of SLAB is a nice
stop-gap measure (and it's a gigantic step up from the old
implementation of "kmalloc"), but it is *not* a done deal.
There are hundreds of places in the kernel where pools of
similar-lifetime objects with well-defined constructors and
destructors should be given their own kmem_cache. (I've stuffed the
"dcache" and "dnames" into their own caches and cut my locked-up pages
by a factor of 4, and this isn't even a good example: "dcache" entries
have variable lifetimes, and I haven't bothered writing constructors
and destructors!!)
I highly recommend the Usenix article referenced in "linux/mm/slab.c"
as required reading for anyone who can't figure out why the mess of
code in "mm/slab.c" is really worth using.
Kevin <buhr@stat.wisc.edu>