lkml.org 
[lkml]   [2008]   [Aug]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
Patch in this message
/
SubjectRe: VolanoMark regression with 2.6.27-rc1
From
Date
On Wed, 2008-08-20 at 15:24 +0800, Zhang, Yanmin wrote:
> On Mon, 2008-08-18 at 10:51 +0530, Dhaval Giani wrote:
> > > > > > > So with kernel 2.6.27-rc1, the successful wakeup_affine is about
> > > > > > > double of the one of 2.6.27-rc1
> > > > > > > on domain 0, but about 10 times on domain 1. That means more tasks are
> > > > > > > woken up on waker cpus.
> > > > > > >
> > > > > > > Does that mean it doesn't follow cache-hot checking?
> > > > > >
> > > > > > I'm a bit puzzled, but you're right - I too noticed that volanomark is
> > > > > > _very_ sensitive to affine wakeups.
> > > > > >
> > > > > > I'll try and find what changed in that code for GROUP=n.
> > > > >
> > > > > hi Yanmin,
> > > > >
> > > > > I was wondering if you could send me your config and what sysctls you
> > > > > have set. I have not been able to reproduce the 2.6.26 -> 2.6.27-rc1
> > > > > GROUP=n regression.
> > > > Pls. see the attachment. As for sysctl, I just set /proc/sys/kernel/sched_compat_yield=1.
> > > >
> > > > I am wondering if the load balance causes the regression when group=n. I manually delete
> > > > all GROUP codes and do a diff against 26 and 27-rc1.
> > > >
> > >
> > > You can disable load balancing by being in uniprocessor mode.
> > >
> >
> > Hi,
> >
> > I can see this regression only with sched_compat_yield=1. Some numbers
> > though, I see a 5% regression with max_cpus=1 whereas close to 50% with
> > SMP on a 8 way.
> After reverting below patch, volanoMark regression becomes less than 2% with CONFIG_GROUP_SCHED=n
> on my 8-core stoakely. The improvement on 16-core tigerton is about 44%, but there is still about
> 20% regression, comparing with 2.6.26_nogroup.
>
>
> commit 93b75217df39e6d75889cc6f8050343286aff4a5
> Author: Peter Zijlstra <a.p.zijlstra@chello.nl>
> Date: Fri Jun 27 13:41:33 2008 +0200
>
> sched: disable source/target_load bias
>
> The bias given by source/target_load functions can be very large, disable
> it by default to get faster convergence.
>
> Signed-off-by: Peter Zijlstra <peterz@infradead.org>
> Cc: Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>
> Cc: Mike Galbraith <efault@gmx.de>
> Signed-off-by: Ingo Molnar <mingo@elte.hu>
>
>
>
> This patch adds a new feature LB_BIAS, but uses it with a NOT, so I lost it when I tested
> single sched feature one by one. That also explains why wake_affine and load_balance_newidle
> have more successful task pulling with kernel 2.6.27-rc, because MC and CPU domain's wake_idx
> is 1, so this patch has impact on them.
>
> Dhaval, could you test it on your 8-way machine?

Ah - I assumed you already tried that knob since you mentioned fiddling
with the various feature flags.

And I must admit to having overlooked the effect on wake_affine..

Chris, could you see the effect of this on smp group fairness?

---
diff --git a/kernel/sched_features.h b/kernel/sched_features.h
index 862b06b..9353ca7 100644
--- a/kernel/sched_features.h
+++ b/kernel/sched_features.h
@@ -8,6 +8,6 @@ SCHED_FEAT(SYNC_WAKEUPS, 1)
SCHED_FEAT(HRTICK, 1)
SCHED_FEAT(DOUBLE_TICK, 0)
SCHED_FEAT(ASYM_GRAN, 1)
-SCHED_FEAT(LB_BIAS, 0)
+SCHED_FEAT(LB_BIAS, 1)
SCHED_FEAT(LB_WAKEUP_UPDATE, 1)
SCHED_FEAT(ASYM_EFF_LOAD, 1)



\
 
 \ /
  Last update: 2008-08-20 09:43    [W:0.221 / U:1.036 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site