mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Vaidyanathan Srinivasan <svaidy@linux.vnet.ibm.com>
To: Linux Kernel <linux-kernel@vger.kernel.org>,
	Suresh B Siddha <suresh.b.siddha@intel.com>,
	Venkatesh Pallipadi <venkatesh.pallipadi@intel.com>,
	Peter Zijlstra <a.p.zijlstra@chello.nl>,
	Ingo Molnar <mingo@elte.hu>, Dipankar Sarma <dipankar@in.ibm.com>,
	Vatsa <vatsa@linux.vnet.ibm.com>,
	Gautham R Shenoy <ego@in.ibm.com>,
	Andi Kleen <andi@firstfloor.org>,
	David Collier-Brown <davecb@sun.com>,
	Tim Connors <tconnors@astro.swin.edu.au>,
	Max Krasnyansky <maxk@qualcomm.com>,
	Gregory Haskins <gregory.haskins@gmail.com>
Subject: Re: [RFC PATCH v5 3/7] sched: nominate preferred wakeup cpu
Date: Mon, 15 Dec 2008 17:44:06 +0530	[thread overview]
Message-ID: <20081215121406.GQ5457@dirshya.in.ibm.com> (raw)
In-Reply-To: <20081215064056.GD18403@balbir.in.ibm.com>

* Balbir Singh <balbir@linux.vnet.ibm.com> [2008-12-15 12:10:56]:

> * Vaidyanathan Srinivasan <svaidy@linux.vnet.ibm.com> [2008-12-11 23:12:57]:
> 
> > When the system utilisation is low and more cpus are idle,
> > then the process waking up from sleep should prefer to
> > wakeup an idle cpu from semi-idle cpu package (multi core
> > package) rather than a completely idle cpu package which
> > would waste power.
> > 
> > Use the sched_mc balance logic in find_busiest_group() to
> > nominate a preferred wakeup cpu.
> > 
> > This info can be sored in appropriate sched_domain, but
> > updating this info in all copies of sched_domain is not
> > practical.  Hence this information is stored in root_domain
> > struct which is one copy per partitioned sched domain.
> > The root_domain can be accessed from each cpu's runqueue
> > and there is one copy per partitioned sched domain.
> > 
> > Signed-off-by: Vaidyanathan Srinivasan <svaidy@linux.vnet.ibm.com>
> > ---
> > 
> >  kernel/sched.c |   12 ++++++++++++
> >  1 files changed, 12 insertions(+), 0 deletions(-)
> > 
> > diff --git a/kernel/sched.c b/kernel/sched.c
> > index 6bea99b..0918677 100644
> > --- a/kernel/sched.c
> > +++ b/kernel/sched.c
> > @@ -493,6 +493,14 @@ struct root_domain {
> >  #ifdef CONFIG_SMP
> >  	struct cpupri cpupri;
> >  #endif
> > +#if defined(CONFIG_SCHED_MC) || defined(CONFIG_SCHED_SMT)
> > +	/*
> > +	 * Preferred wake up cpu nominated by sched_mc balance that will be
> > +	 * used when most cpus are idle in the system indicating overall very
> > +	 * low system utilisation. Triggered at POWERSAVINGS_BALANCE_WAKEUP(2)
> 
> Is the root domain good enough?
> 
> What is POWERSAVINGS_BALANCE_WAKEUP(2), is it sched_mc == 2?

Yes

> 
> > +	 */
> > +	unsigned int sched_mc_preferred_wakeup_cpu;
> > +#endif
> >  };
> > 
> >  /*
> > @@ -3407,6 +3415,10 @@ out_balanced:
> > 
> >  	if (this == group_leader && group_leader != group_min) {
> >  		*imbalance = min_load_per_task;
> > +		if (sched_mc_power_savings >= POWERSAVINGS_BALANCE_WAKEUP) {
> 
> OK, it is :) (for the question above). Where do we utilize the set
> sched_mc_preferred_wakeup_cpu?

We use this nominated cpu in wake_idle() in sched_fair.c

> > +			cpu_rq(this_cpu)->rd->sched_mc_preferred_wakeup_cpu =
> > +					first_cpu(group_leader->cpumask);
> 
> Everytime we balance, we keep replacing rd->sched_mc_preferred_wake_up
> with group_lead->cpumask? My big concern is that we do this without

The first_cpu in the group_leader's mask.  The nomination is a cpu
number.

> checking if the group_leader has sufficient capacity (after it will
> pull in tasks since we made the checks for nr_running and capacity).

You are correct.  But if we are running find_busiest_group(), then we
are in load_balance() code on this cpu and exit from this function
should recommend a pull task.  The cpu evaluating the load on
group_leader will be the nominated load_balancer cpu for this
group/domain.  Nobody would have pushed task to our group while we are
at this function.  However interrupts and other preemptable corner
cases may change the load with RT tasks etc.  Generally the
computed load on _this_ group (group_leader) will not change.  

What you are pointing out is valid for other group loads like
group_min etc.

--Vaidy

  reply	other threads:[~2008-12-15 12:11 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-12-11 17:42 [RFC PATCH v5 0/7] Tunable sched_mc_power_savings=n Vaidyanathan Srinivasan
1970-01-01  0:13 ` Pavel Machek
2008-12-14 20:08   ` Vaidyanathan Srinivasan
2008-12-15  8:18     ` Peter Zijlstra
2008-12-11 17:42 ` [RFC PATCH v5 1/7] sched: Framework for sched_mc/smt_power_savings=N Vaidyanathan Srinivasan
2008-12-11 18:55   ` Balbir Singh
2008-12-11 19:07     ` Vaidyanathan Srinivasan
2008-12-11 17:42 ` [RFC PATCH v5 2/7] sched: favour lower logical cpu number for sched_mc balance Vaidyanathan Srinivasan
2008-12-15  6:12   ` Balbir Singh
2008-12-15 12:05     ` Vaidyanathan Srinivasan
2008-12-11 17:42 ` [RFC PATCH v5 3/7] sched: nominate preferred wakeup cpu Vaidyanathan Srinivasan
2008-12-15  6:40   ` Balbir Singh
2008-12-15 12:14     ` Vaidyanathan Srinivasan [this message]
2008-12-11 17:43 ` [RFC PATCH v5 4/7] sched: bias task wakeups to preferred semi-idle packages Vaidyanathan Srinivasan
2008-12-15  7:01   ` Balbir Singh
2008-12-15  8:25     ` Peter Zijlstra
2008-12-15  8:33       ` Peter Zijlstra
2008-12-15  8:46         ` Balbir Singh
2008-12-15 12:25           ` Vaidyanathan Srinivasan
2008-12-15 18:02             ` Balbir Singh
2008-12-16  7:25               ` Vaidyanathan Srinivasan
2008-12-15  8:43       ` Balbir Singh
2008-12-11 17:43 ` [RFC PATCH v5 5/7] sched: activate active load balancing in new idle cpus Vaidyanathan Srinivasan
2008-12-11 17:43 ` [RFC PATCH v5 6/7] sched: add SD_BALANCE_NEWIDLE at MC and CPU level for sched_mc>0 Vaidyanathan Srinivasan
2008-12-11 17:43 ` [RFC PATCH v5 7/7] sched: idle_balance() does not call load_balance_newidle() Vaidyanathan Srinivasan
2008-12-15  7:02   ` Balbir Singh

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20081215121406.GQ5457@dirshya.in.ibm.com \
    --to=svaidy@linux.vnet.ibm.com \
    --cc=a.p.zijlstra@chello.nl \
    --cc=andi@firstfloor.org \
    --cc=davecb@sun.com \
    --cc=dipankar@in.ibm.com \
    --cc=ego@in.ibm.com \
    --cc=gregory.haskins@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=maxk@qualcomm.com \
    --cc=mingo@elte.hu \
    --cc=suresh.b.siddha@intel.com \
    --cc=tconnors@astro.swin.edu.au \
    --cc=vatsa@linux.vnet.ibm.com \
    --cc=venkatesh.pallipadi@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®