Re: [PATCH 14/15] sched: Conditionally limit __cpu_power whenchild sched domain has type NODE

[Andreas Herrmann]

On Mon, Aug 24, 2009 at 05:35:32PM +0200, Peter Zijlstra wrote:
> On Thu, 2009-08-20 at 15:45 +0200, Andreas Herrmann wrote:
> > We need this in case of performance policy. All sched_groups in
> > child's parent domain (MN in this case) should be limited such that
> > tasks are balanced among these sched_groups.
> 
> /me fails at correlating the above changelog and the below patch.

> So here we go mess up cpu_power again in order to invluence the
> placement policy?

Yep, to restrict the capacity of sched_groups in MN domain.

But you pointed already out that messing up cpu_power is
unwanted.

So I have to look for an alternative to influence placement policy
such that cpu_power is kept intact and always properly normalized.
 
> > Signed-off-by: Andreas Herrmann <andreas.herrmann3@xxxxxxx>
> > ---
> >  kernel/sched.c |    4 ++--
> >  1 files changed, 2 insertions(+), 2 deletions(-)
> > 
> > diff --git a/kernel/sched.c b/kernel/sched.c
> > index 0c950dc..ab88d88 100644
> > --- a/kernel/sched.c
> > +++ b/kernel/sched.c
> > @@ -8555,11 +8555,11 @@ static void init_sched_groups_power(int cpu, struct sched_domain *sd)
> >  	 */
> >  	if (!(sd->flags & SD_POWERSAVINGS_BALANCE) &&
> >  	    ((child->flags &
> > -	      (SD_SHARE_CPUPOWER | SD_SHARE_PKG_RESOURCES)))) {
> > +	      (SD_SHARE_CPUPOWER | SD_SHARE_PKG_RESOURCES)) ||
> > +	     (child->level == SD_LV_NODE))) {
> >  		sd->groups->__cpu_power = 0;
> >  		sg_inc_cpu_power(sd->groups, SCHED_LOAD_SCALE);
> >  	}
> > -
> >  }
> >  
> >  /*
> 

Andreas

-- 
Operating | Advanced Micro Devices GmbH
  System  | Karl-Hammerschmidt-Str. 34, 85609 Dornach b. München, Germany
 Research | Geschäftsführer: Thomas M. McCoy, Giuliano Meroni
  Center  | Sitz: Dornach, Gemeinde Aschheim, Landkreis München
  (OSRC)  | Registergericht München, HRB Nr. 43632


--
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/