lkml.org 
[lkml]   [2007]   [Dec]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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


\
 
 \ /
  Last update: 2007-12-21 23:55    [W:0.116 / U:0.212 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site