From: Peter Zijlstra <peterz@infradead.org>
To: Suresh Siddha <suresh.b.siddha@intel.com>
Cc: Ingo Molnar <mingo@elte.hu>, Venki Pallipadi <venki@google.com>,
Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
Mike Galbraith <efault@gmx.de>,
linux-kernel <linux-kernel@vger.kernel.org>,
Tim Chen <tim.c.chen@linux.jf.intel.com>,
"Shi, Alex" <alex.shi@intel.com>
Subject: Re: [patch 3/6] sched, nohz: sched group, domain aware nohz idle load balancing
Date: Tue, 29 Nov 2011 10:45:44 +0100 [thread overview]
Message-ID: <1322559944.2921.192.camel@twins> (raw)
In-Reply-To: <1322524692.21329.69.camel@sbsiddha-desk.sc.intel.com>
On Mon, 2011-11-28 at 15:58 -0800, Suresh Siddha wrote:
> On Thu, 2011-11-24 at 03:53 -0800, Peter Zijlstra wrote:
> > On Fri, 2011-11-18 at 15:03 -0800, Suresh Siddha wrote:
> > > Make nohz idle load balancing more scalabale by using the nr_busy_cpus in
> > > the struct sched_group_power.
> > >
> > > Idle load balance is kicked on one of the idle cpu's when there is atleast
> > > one idle cpu and
> > >
> > > - a busy rq having more than one task or
> > >
> > > - a busy scheduler group having multiple busy cpus that exceed the sched group
> > > power or
> > >
> > > - for the SD_ASYM_PACKING domain, if the lower numbered cpu's in that
> > > domain are idle compared to the busy ones.
> > >
> > > This will help in kicking the idle load balancing request only when
> > > there is a real imbalance. And once it is mostly balanced, these kicks will
> > > be minimized.
> > >
> > > These changes helped improve the workload that is context switch intensive
> > > between number of task pairs by 2x on a 8 socket NHM-EX based system.
> >
> > OK, but the nohz idle balance will still iterate the whole machine
> > instead of smaller parts, right?
>
> In the current series, yes. one idle cpu spending a bit more time doing
> idle load balancing might be better compared to waking up multiple idle
> cpu's from deep c-states.
>
> But if needed, we can easily partition the nohz idle load balancer load
> to multiple idle cpu's. But we need a balance between the right
> partition size vs how many idle cpu's we need to bring out of tickless
> mode to do this idle load balancing.
>
> Current proposed series already has the infrastructure to identify
> which scheduler domain has the imbalance. Perhaps we can use that to do
> the nohz idle load balancing only for that domain.
Yeah, trouble with that is if tehre's inter-domain balance things, like
for example balance for power, where you want to idle a domain. If you
only ever look within the one domain, you'll never see the possibility
to move your last one task to this other domain.
Pesky stuff that.
next prev parent reply other threads:[~2011-11-29 9:46 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-11-18 23:03 [patch 0/6] sched, nohz: load balancing patches Suresh Siddha
2011-11-18 23:03 ` [patch 1/6] sched, nohz: introduce nohz_flags in the struct rq Suresh Siddha
2011-11-24 10:24 ` Peter Zijlstra
2011-11-28 23:59 ` Suresh Siddha
2011-11-29 9:47 ` Peter Zijlstra
2011-11-18 23:03 ` [patch 2/6] sched, nohz: track nr_busy_cpus in the sched_group_power Suresh Siddha
2011-11-18 23:03 ` [patch 3/6] sched, nohz: sched group, domain aware nohz idle load balancing Suresh Siddha
2011-11-24 11:47 ` Peter Zijlstra
2011-11-28 23:51 ` Suresh Siddha
2011-11-29 9:44 ` Peter Zijlstra
2011-12-01 1:03 ` Suresh Siddha
2011-12-01 1:17 ` Suresh Siddha
2011-12-01 8:36 ` Peter Zijlstra
2011-11-24 11:53 ` Peter Zijlstra
2011-11-28 23:58 ` Suresh Siddha
2011-11-29 9:45 ` Peter Zijlstra [this message]
2011-11-18 23:03 ` [patch 4/6] sched, nohz: cleanup the find_new_ilb() using sched groups nr_busy_cpus Suresh Siddha
2011-11-18 23:03 ` [patch 5/6] sched: disable sched feature TTWU_QUEUE by default Suresh Siddha
2011-11-19 4:30 ` Mike Galbraith
2011-11-19 4:41 ` Mike Galbraith
2011-11-18 23:03 ` [patch 6/6] sched: fix the sched group node allocation for SD_OVERLAP domain Suresh Siddha
2011-12-06 9:51 ` [tip:sched/core] sched: Fix the sched group node allocation for SD_OVERLAP domains tip-bot for Suresh Siddha
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=1322559944.2921.192.camel@twins \
--to=peterz@infradead.org \
--cc=alex.shi@intel.com \
--cc=efault@gmx.de \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=suresh.b.siddha@intel.com \
--cc=tim.c.chen@linux.jf.intel.com \
--cc=vatsa@linux.vnet.ibm.com \
--cc=venki@google.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