Re: [Bug #10638] sysbench+mysql(oltp, readonly) 30% regressionwith 2.6.26-rc1

From: Ingo Molnar
Date: Wed Jun 04 2008 - 07:20:28 EST



* Zhang, Yanmin <yanmin_zhang@xxxxxxxxxxxxxxx> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/