Messages in this thread | | | Date | Wed, 14 Jan 2009 16:45:15 +0200 | From | "Pekka Enberg" <> | Subject | Re: [patch] SLQB slab allocator |
| |
Hi Nick,
On Wed, Jan 14, 2009 at 4:22 PM, Nick Piggin <npiggin@suse.de> wrote: > The problem is there was apparently no plan for resolving the SLAB vs SLUB > strategy. And then features and things were added to one or the other one. > But on the other hand, the SLUB experience was a success in a way because > there were a lot of performance regressions found and fixed after it was > merged, for example.
That's not completely true. I can't speak for Christoph, but the biggest problem I have is that I have _no way_ of reproducing or analyzing the regression. I've tried out various benchmarks I have access to but I haven't been able to find anything.
The hypothesis is that SLUB regresses because of kmalloc()/kfree() ping-pong between CPUs and as far as I understood, Christoph thinks we can improve SLUB with the per-cpu alloc patches and the freelist management rework.
Don't get me wrong, though. I am happy you are able to work with the Intel engineers to fix the long standing issue (I want it fixed too!) but I would be happier if the end-result was few simple patches against mm/slub.c :-).
On Wed, Jan 14, 2009 at 4:22 PM, Nick Piggin <npiggin@suse.de> wrote: > I'd love to be able to justify replacing SLAB and SLUB today, but actually > it is simply never going to be trivial to discover performance regressions. > So I don't think outright replacement is great either (consider if SLUB > had replaced SLAB completely).
If you ask me, I wish we *had* removed SLAB so relevant people could have made a huge stink out of it and the regression would have been taken care quickly ;-).
Pekka
| |