a brief look
new SLEB memory allocator last week. Since then, Christoph Lameter has
posted a second revision of the
, but subsequent discussion suggests that SLEB is not likely to
find its way into the mainline.
The main detractor at the outset was Nick Piggin, author of the unmerged SLQB allocator. Nick saw SLEB
as a step forward from SLUB, which he suggests should never have been merged:
I don't think SLUB ever proved itself very well. The selling points
were some untestable handwaving about how queueing is bad and
jitter is bad, ignoring the fact that queues could be shortened and
periodic reaping disabled at runtime with SLAB style of
allocator. It also has relied heavily on higher order allocations
which put great strain on hugepage allocations and page reclaim
(witness the big slowdown in low memory conditions when tmpfs was
using higher order allocations via SLUB).
What Nick would like to see at this point is not another in-kernel slab
allocator (not even SLQB), but, instead, an effort to improve slab itself,
which, he says, is already pretty close to optimal. And, regardless, Linus
has made it clear that he's not interested
in merging more allocators:
I'm not going to merge YASA that will stay around
for years, not improve on anything, and will just mean that there are some
bugs that developers don't see because they depend on some subtle
interaction with the sl*b allocator.
Nick's plan is to start by cleaning up the slab allocator to make the code
more approachable than it is now. Then, any performance problems can be
carefully fixed up, with an emphasis on not causing performance regressions
elsewhere. Over time, he says, we should get farther with a single
allocator that is used (and tested) by everybody than by ripping out code
with a long development history and replacing it with something new and untried.
to post comments)