All of lore.kernel.org
 help / color / mirror / Atom feed
From: Balbir Singh <balbir@linux.vnet.ibm.com>
To: Peter Zijlstra <a.p.zijlstra@chello.nl>,
	Linux Kernel <linux-kernel@vger.kernel.org>,
	Suresh B Siddha <suresh.b.siddha@intel.com>,
	Venkatesh Pallipadi <venkatesh.pallipadi@intel.com>,
	Ingo Molnar <mingo@elte.hu>, Dipankar Sarma <dipankar@in.ibm.com>,
	Balbir Singh <balbir@linux.vnet.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 v3 3/5] sched: nominate preferred wakeup cpu
Date: Tue, 11 Nov 2008 22:19:46 +0530	[thread overview]
Message-ID: <4919B7AA.8060801@linux.vnet.ibm.com> (raw)
In-Reply-To: <20081111164825.GS4646@dirshya.in.ibm.com>

Vaidyanathan Srinivasan wrote:
> * Peter Zijlstra <a.p.zijlstra@chello.nl> [2008-11-11 14:43:39]:
> 
>> On Tue, 2008-11-11 at 00:03 +0530, Vaidyanathan Srinivasan wrote:
>>> 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.  For now lets try with a per-cpu variable
>>> pointing to a common storage in partition sched domain
>>> attribute.  Global variable may not work in partitioned
>>> sched domain case.
>> Would it make sense to place the preferred_wakeup_cpu stuff in the
>> root_domain structure we already have?
> 
> Yep, that will be a good idea.  We can get to root_domain from each
> CPU's rq and we can get rid of the per-cpu pointers for
> preferred_wakeup_cpu as well. I will change the implementation and
> re-post.

Did you see Vatsa's comments? root_domain will no work if you have more than one
preferred_wakeup_cpu per domain.

-- 
	Balbir

  reply	other threads:[~2008-11-11 16:56 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-11-10 18:32 [RFC PATCH v3 0/5] Tunable sched_mc_power_savings=n Vaidyanathan Srinivasan
2008-11-10 18:33 ` [RFC PATCH v3 1/5] sched: Framework for sched_mc/smt_power_savings=N Vaidyanathan Srinivasan
2008-11-10 18:33 ` [RFC PATCH v3 2/5] sched: favour lower logical cpu number for sched_mc balance Vaidyanathan Srinivasan
2008-11-10 18:33 ` [RFC PATCH v3 3/5] sched: nominate preferred wakeup cpu Vaidyanathan Srinivasan
2008-11-11 13:43   ` Peter Zijlstra
2008-11-11 14:07     ` Gregory Haskins
2008-11-11 15:21       ` Srivatsa Vaddagiri
2008-11-11 15:26         ` Peter Zijlstra
2008-11-11 17:15           ` Vaidyanathan Srinivasan
2008-11-11 17:17       ` Vaidyanathan Srinivasan
2008-11-11 16:48     ` Vaidyanathan Srinivasan
2008-11-11 16:49       ` Balbir Singh [this message]
2008-11-11 17:27         ` Vaidyanathan Srinivasan
2008-11-10 18:33 ` [RFC PATCH v3 4/5] sched: bias task wakeups to preferred semi-idle packages Vaidyanathan Srinivasan
2008-11-10 18:33 ` [RFC PATCH v3 5/5] sched: activate active load balancing in new idle cpus Vaidyanathan Srinivasan
2008-11-11 13:47   ` Peter Zijlstra
2008-11-11 17:04     ` Vaidyanathan Srinivasan
2008-11-11 17:21       ` Peter Zijlstra
2008-11-11 17:31         ` Vaidyanathan Srinivasan
2008-11-10 18:50 ` [RFC PATCH v3 0/5] Tunable sched_mc_power_savings=n Peter Zijlstra
2008-11-11  4:52   ` Vaidyanathan Srinivasan

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=4919B7AA.8060801@linux.vnet.ibm.com \
    --to=balbir@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.