Slab Allocator Performance Comparison

Question

Hi,

I'm looking at revamping our malloc() in our operating system kernel. We currently use dlmalloc, but I'd like a homebrew solution that we can edit without having to work on a thousand-line file.

I've decided to look into the slab allocator (Bonwick94) and I believe it's the right choice. So far I understand the concept and am ready to implement it. However, I'd like to get a picture of the performance comparison before I begin work.

Assuming that layers below the malloc (vmem, pmem, etc...) have neglible impact, how does the slab allocator compare to, say, dlmalloc, and other common malloc implementations (buddy, best-fit/first-fit, hybrids)?

Answer 1

i believe that the slab allocator was at least part of the inspiration for dlmalloc, and the basic outline is considered to be the best overall combination of tradeoffs for a general purpose allocator system. Generic "one-size-fits-all" allocators -no pun intended- at the level of abstraction of "best-fit", "next-fit", etc, typically won't cut it; a single algorithm is just too limited. So a combination, say, a best-fit used together with a slab allocator, will perform much more satisfactorily.

Using a hierarchy of "sub allocators" with behaviors that are tailored to usage profiles in your environment is easier than it sounds - for example, using one allocation system for "small" blocks (however that might be defined in your environment), and another for "large" can greatly affect speed and fragmentation performance, My personal interest is in using block "lifetime" characteristics as an aid to allocator selection.

But bottom line, I don't believe in a single allocation strategy; but you can get a lot of performance improvement out of a hybrid of just 2 or 3 (at most) suballocators; at the same time, you'll probably end up with the same 1000 line size with that approach.