|| ||Linus Torvalds <torvalds-AT-linux-foundation.org>|
|| ||Christoph Lameter <clameter-AT-sgi.com>|
|| ||Re: Major regression on hackbench with SLUB (more numbers)|
|| ||Fri, 21 Dec 2007 08:44:42 -0800 (PST)|
|| ||Ingo Molnar <mingo-AT-elte.hu>, Steven Rostedt <rostedt-AT-goodmis.org>,
Andrew Morton <akpm-AT-linux-foundation.org>,
Peter Zijlstra <a.p.zijlstra-AT-chello.nl>,
Christoph Hellwig <hch-AT-infradead.org>,
"Rafael J. Wysocki" <rjw-AT-sisk.pl>|
On Fri, 21 Dec 2007, Christoph Lameter wrote:
> So we have 3 different regimes here (order 0):
[ ... ]
> The regression is contained because:
[ ... ]
Christoph, *NONE* of these arguments matter at all.
The only thing that matters is the simple fact that real-life benchmarks
show that SLUB is worse. It doesn't matter one whit that you can say that
it's better under some circumstance that either isn't triggered, or when
setting unrealistic and unusable parameters (ie big internal slab orders).
> We could address this issue by:
> But given all the boundaries for the contention I would think that it is
> not worth addressing.
.. and this seems to be the single biggest reason to just say "revert SLUB
If you aren't even motivated to fix the problems that have been reported,
then SLUB isn't even a _potential_ solution, it's purely a problem, and
since I am not IN THE LEAST interested in having three different
allocators around, SLUB is going to get axed.
In other words, here's the low-down:
a) either SLUB can replace SLAB, or SLUB is going away
This isn't open for discussion, Christoph. This was the rule back when
it got merged in the first place.
b) if SLUB performs worse than SLAB on real loads (TPC-C certainly being
one, and while hackbench may be borderline, it's certainly less
borderline than others), then SLUB cannot replace SLAB.
c) If you aren't even interested in trying to fix it and are ignoring
the reports, there is not even a _potential_ for SLUB for getting over
these problems, and I should disable it and we should get over it as
soon as possible, and this whole discussion is pretty much ended.
See? It really is that simple. Either you say "Hell yes, I'll fix it", or
SLUB goes away. There simply is no orther choice.
When you say "not worth addressing", that to me is a clear an unambiguous
"let's remove SLUB".
The main reason for SLUB in the first place was SGI concerns. You seem to
think that _only_ SGI concerns matter. Wrong. If SLUB remains a SGI-only
thing and you don't fix it for other users, then SLUB gets reverted from
the standard kernel.
That's all. And it's not really worth discussing.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to firstname.lastname@example.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
to post comments)