* Ingo Molnar <[email protected]> wrote:
> * Christoph Lameter <[email protected]> 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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
