Re: Major regression on hackbench with SLUB (more numbers)

Christoph Lameter
2007-12-21T16:26:56Z

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.