Re: dbench 15% regression with 2.6.28-rc1

["Zhang, Yanmin" <yanmin_zhang@linux.intel.com>]

On Tue, 2008-10-28 at 16:41 +0800, Zhang, Yanmin wrote:
> Comparing with 2.6.27, dbench result has regression with 2.6.28-rc1 on 2 machines.
> 1) 8-core stoakley: 15%
> 2) 8 core+mutl-thread new-model x86-64: 12%
> 
> Bisect located below patch.
> 
> 695698500912c4479ddf4723e492de3970ff8530 is first bad commit
> commit 695698500912c4479ddf4723e492de3970ff8530
> Author: Peter Zijlstra <a.p.zijlstra@chello.nl>
> Date:   Tue Sep 23 14:54:23 2008 +0200
> 
>     sched: rework wakeup preemption
>     
>     Rework the wakeup preemption to work on real runtime instead of
>     the virtual runtime. This greatly simplifies the code.
>     
>     Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
>     Signed-off-by: Ingo Molnar <mingo@elte.hu>
> 
> 
> I reverted the patch against 2.6.28-rc2 and the regression mostly disappears
> on 8-core stoakley and 8-core+multiThread x86-64 machines.
> 
> 
> On other 2 machines, I see improvement instead of regression.
> 1) 16-core tigerton: improvement 48%
> 2) 8-core+hyperThreading tulsa: 10%.
> I just checked it by reverting above patch to see if the patch improves it. At least
> it isn't on tigerton. I'm doing a new bisect on tigerton to see what patch improves
> dbench result.
The improvement on tigerton isn't caused by the patch. It seems it is caused by
other scheduler patches.

Well, comparing with 2.6.27, the result of sysbench+mysql (oltp readonly) with 2.6.28-rc2
has about 10% improvement, especially with high thread number. I located that's casued
by the rework_wakeup_preemption patch.

So the patch improves oltp result, but downgrades dbench result.

-yanmin