Re: The Slab Allocator (Was: Re: New dcache not using slab allocator?)

Kevin Buhr (
05 Aug 1997 20:04:05 -0500

Mark Hemment <> writes:
> As the implementor of the SLAB, I was quite shocked to see mm/simp.c
> appear in the kernel source....

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