Messages in this thread | | | Date | Fri, 21 Dec 2007 08:26:47 -0800 (PST) | From | Christoph Lameter <> | Subject | Re: Major regression on hackbench with SLUB (more numbers) |
| |
On Fri, 21 Dec 2007, Ingo Molnar wrote:
> and this is not the only regression: > > http://lkml.org/lkml/2007/10/4/290 > > _6%_ TPC-C regression. That's _a lot_ in TPC-C terms. > > and just like in this case there were very clear profiles posted. I > proffer, reading back the whole thread, that if you fix hackbench you > have fixed TPC-C as well.
There are patches pending to address these issues. AFAICT Intel is testing if the regression is still there. There is no way for me to verify what is going on there and there is the constant difficulty of getting detailed information about what is going on at Intel. Every couple of month I get a result from that test. Its a really crappy situation where a lot of confusing information is passed around.
> So i believe you should either send some sensible fixes _NOW_, or admit > that the "no queues" NIH nonsense of SLUB doesnt work and do an edible, > incremental patchset against SLAB to bring in the debuggability features > of SLUB without killing SLAB's performance. (And fix the NUMA alien > cache problem along the lines suggested before - perhaps initially by > making 'noaliencache' the default bootup option.) And we obviously must > revert the default in 2.6.24 to SLAB as well.
The fixes to the alien that you proposed do not work since we would still have to check for the need to put the object into alien cache. The checks for the locality of each object are the main cause of trouble when freeing in SLAB.
SLUB is generally performance wise superior to SLAB as demonstrated by my measurements that you reviewed too. In addition SLUB has many improvements over SLAB. Its not only the runtime debuggability which would be difficult to add since there would be numerous runtime checks in critical code paths that would cause regressions.
| |