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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 21 Dec 2007 08:44:42 -0800 (PST)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Christoph Lameter <clameter@....com>
cc:	Ingo Molnar <mingo@...e.hu>, Steven Rostedt <rostedt@...dmis.org>,
	LKML <linux-kernel@...r.kernel.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Christoph Hellwig <hch@...radead.org>,
	"Rafael J. Wysocki" <rjw@...k.pl>
Subject: Re: Major regression on hackbench with SLUB (more numbers)

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 
entirely".

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.

    See (a)

 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. 

			Linus

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