Re: [tip:sched/core] sched: Fix capacity calculations for SMT4

[Michael Neuling <mikey@neuling.org>]

In message <1276152536.2046.2479.camel@twins> you wrote:
> On Thu, 2010-06-10 at 09:03 +1000, Michael Neuling wrote:
> > Peter,
> >=20
> > It looks like when this was pushed to Ingo, some of the logic was
> > changed.  rt_freq_influence() became fix_small_capacity() but the return
> > values for these two functions are opposite (return 1 =3D> return 0 and
> > visa versa]]).
> >=20
> > This was changed in the sibling test (return 1 =3D> return 0), but the
> > check for the change in cpu power due to freq and rt was not.
> >=20
> > So either the return values need to be changed at the end of
> > fix_small_capacity() or the cpu_power test needs to be the other way
> > around.  Below changes the cpu_power test as it brings it more inline
> > with the comment above it.
> >=20
> > Without this the asymmetric packing doesn't work.
> 
> D'oh fully my fault for cleaning up.
> 
> Thanks, I'll make sure it gets fixed.

Peter,

I've not see this fix (or the doc/comment update patch from here
https://patchwork.kernel.org/patch/105256/) hit Ingo tip tree as yet.
When you are likely to push it to him?

Mikey

> 
> > Subject: sched: fix the CPU power test for fix_small_capacity
> >=20
> > The CPU power test is the wrong way around in fix_small_capacity.
> >=20
> > This was due to a small changes made in the posted patch on lkml to what
> > was was taken upstream.
> >=20
> > This patch fixes asymmetric packing for POWER7.
> >=20
> > Signed-off-by: Michael Neuling <mikey@neuling.org>
> >=20
> > Index: linux-2.6-ozlabs/kernel/sched_fair.c
> > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> > --- linux-2.6-ozlabs.orig/kernel/sched_fair.c
> > +++ linux-2.6-ozlabs/kernel/sched_fair.c
> > @@ -2354,7 +2354,7 @@ fix_small_capacity(struct sched_domain *
> >  	/*
> >  	 * If ~90% of the cpu_power is still there, we're good.
> >  	 */
> > -	if (group->cpu_power * 32 < group->cpu_power_orig * 29)
> > +	if (group->cpu_power * 32 > group->cpu_power_orig * 29)
> >  		return 1;
> > =20
> >  	return 0;
> >=20
>