lkml.org 
[lkml]   [2008]   [Jun]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [Bug #10638] sysbench+mysql(oltp, readonly) 30% regression with 2.6.26-rc1

* Zhang, Yanmin <yanmin_zhang@linux.intel.com> wrote:

>
> On Fri, 2008-05-30 at 11:45 +0200, Ingo Molnar wrote:
> > Yanmin,
> >
> > could you please check whether the performance regressions you
> > noticed are now fixed in upstream -git? [make sure merge
> > a7f75d3bed28 is included]
> >
> > i believe most of the regressions to 2.6.25 you found should be
> > addressed - if not, please let me know which one is still hurting.
>
> Most regressions are fixed.

great - thanks for the exhaustive testing! In fact there should be nice
speedups in most of the categories as well ;-)

out of the 5 issues, only one is inconclusive:

> On 16-thread tulsa machine, hackbench result becomes 34 seconds.
> 2.6.26-rc2's result is 40 seconds and 2.6.26-rc1's is 30 seconds. So
> there is much improvement. On another Montvale machine(supporting
> multi-threading, but I don't turn on it in BIOS), hackbench has the
> similiar behavior.

okay, that's "hackbench 100", which creates a swarm of 2000 runnable
tasks and which is extremely sensitive to wakeup preemption details. It
is a volanomark work-alike, so if volanomark itself works fine (which it
does appear, from your other numbers) and this one regresses a bit, i'm
not sure there's anything fundamental to be worried about.

Quite likely you'll get more stable results if you run it all batched
(which such workload really should):

schedtool -B -e hackbench 100

right?

the 16-thread tulsa machine, how is it laid out physically: 2 sockets, 4
cores per socket, 2 threads per core?

Ingo


\
 
 \ /
  Last update: 2008-06-04 13:23    [W:0.119 / U:0.540 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site