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

[Ingo Molnar <mingo@elte.hu>]

* Ingo Molnar <mingo@elte.hu> wrote:

> * Christoph Lameter <clameter@sgi.com> wrote:
> 
> > Hmmmm... Some tests here on an 8p 8G machine:
> 
> > In an extreme case (boot with slub_min_order=9 to get huge page sized 
> > slabs) SLUB can win against SLAB:
> > 
> > N=10 Time: 0.338	Minimally faster
> > N=20 Time: 0.560	10% faster
> > N=50 Time: 1.353	15% faster
> 
> what's up with this regression? There's been absolutely no activity 
> about it in the last 8 days: upstream still regresses, -mm still 
> regresses and there are no patches posted for testing.
> 
> being able to utilize order-0 pages was supposed to be one of the big 
> plusses of SLUB, so booting with _2MB_ sized slabs cannot be seriously 
> the "fix", right?

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.

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.

	Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/