huh? You got the ordering wrong ;-) SLUB needs to resolve all
regressions relative to SLAB. (or at least have a really good
explanation about why it regresses)
which is of little help if it regresses on other workloads. As we've
seen it, SLUB can be more than 10 times slower on hackbench. You can
tune SLUB to use 2MB pages but of course that's not a production level
system. OTOH, have you tried to tune SLAB in the above benchmark?
link?
that's not a fundamental property of SLAB. It would be an about 10 lines
hack to enable SLAB debugging switchable-on runtime, with the boot flag
defaulting to 'off'.
well that's the nature of caches, but it could be improved: restrict
alien caches along cpusets and demand-allocate them.
the moment you start capturing more memory in SLUB's per cpu queues
(which do exist), you will have the same sort of problem.
again, not a fundamental property of SLAB.
i do appreciate that :-) SLUB was rather easy to "port" to PREEMPT_RT:
it did not need a single line of change. The SLAB portion is a lot
scarier:
dione:~linux-rt.q> diffstat patches/rt-slab-new.patch
1 file changed, 319 insertions(+), 177 deletions(-)
all of these are neat.
How about renaming it to SLAB2 instead of SLUB? The "unqueued" bit is
just stupid NIH syndrome. It's _of course_ queued because it has to. "It
does not have _THAT_ queue as SLAB used to have" is just a silly excuse.
actually, this might be a bug. the DMA caches should be created right
away and filled with a small amount of objects due to stupid 16MB
limitations with certain hardware. Later on a GFP_DMA request might not
be fulfillable. (because that zone is filled up pretty quickly)
Ingo
--