Messages in this thread | | | Date | Wed, 4 Jun 2008 13:19:51 +0200 | From | Ingo Molnar <> | Subject | Re: [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
| |