The SLEB allocator

Longtime LWN readers will know that the kernel does not have just one internal memory allocator. Instead, we have the longstanding "slab" allocator (perennially due to be removed someday), the SLUB allocator (intended for better scalability, but it hasn't been able to beat slab on every test), and the SLOB allocator (a space-efficient allocator for embedded use). There is also the SLQB allocator waiting in the wings, but it has been waiting there long enough that one may wonder if it will ever emerge from there.

All told, one might assume that we have enough allocators. Then again, there are quite a few letters still available in the SL*B namespace, so why not make another one?

Thus Christoph Lameter, author of SLUB, has come forward with the SLEB allocator, which is meant to be a mixture of the best of slab and SLUB. Unlike SLUB, SLEB retains the object queues used by slab, but it also adds a bitmap for object management as well. Also unlike SLUB, there is no storage of metadata in the objects themselves. That is a performance enhancement: if a cache-cold object is allocated or freed, SLEB will not bring it into the cache.

This code is very new; it apparently has not yet been trusted outside of a KVM virtual machine. The long benchmarking process that might lead to merging and, possibly, displacing one of the other allocators has not yet begun. But the code is there, and that's a start.

Index entries for this article
Kernel	Memory management/Slab allocators
Kernel	Slab allocator

---

to post comments

The SLEB allocator

Posted May 20, 2010 12:22 UTC (Thu) by bcopeland (subscriber, #51750) [Link]

This is not a new idea, but it would be interesting if the allocators could also take into account the locality of the user in addition to that of the allocator.

For example, if you are allocating nodes in a linked list, you might give a hint to the allocator to give me an object from a slab where the object is spatially close to "this" one -- even if there is not a lot of temporal locality between the allocations. That could be a win on large, long-lived lists and trees.