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]

Message-ID: <alpine.LFD.0.9999.0712211442000.21557@woody.linux-foundation.org>
Date:	Fri, 21 Dec 2007 14:49:10 -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:
> 
> It obviously can replace it and has replaced it for awhile now.

No. If there are 6% performance regressions on TPC-C, then it CAN NOT 
replace it!

> Well still SLUB is really superior to SLAB in many ways....
> 
> - SLUB is performance wise much faster than SLAB.

No.

Christoph, statements like this is *exactly* why I don't think SLUB can 
make it.

You're closing your eyes to real performace *regression* reports, and then 
you claim thast SLUB is faster, because you find your own microbenchmarks 
that show so for specific loads.

But those specific loads are apparetly never the issue.

So stop saying that SLUB is "much faster", as long as hackbench shows that 
that is simply NOT THE CASE.

It doesn't matter one whit if SLUB is lots faster, if it's faster for 
cases that never matter. So far, I don't think we've *ever* seen any 
actual benchmarks that involve any kind of real use where SLUB is 
really faster, and we have some major examples of SLUB being disastrously 
slower!

Your special-case kmalloc performance tests don't matter, when real user 
programs show the exact opposite effect.

And the fact that you dismiss those real user programs just because you 
have your own test harness is why I'm ready to throw in the towel on SLUB. 

I don't mind performance regressions, but I *do* mind performance 
regressions when the main author then says "look, a helicopter!" and 
points to some totally different thing and claims that the performance 
regression doesn't even exist!

Because those kinds of performance regressions never get fixed, because 
they are ignored.

		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/