From: Peter Zijlstra <peterz@infradead.org>
To: Morten Rasmussen <morten.rasmussen@arm.com>
Cc: "Vincent Guittot" <vincent.guittot@linaro.org>,
"mingo@redhat.com" <mingo@redhat.com>,
"Dietmar Eggemann" <dietmar.eggemann@arm.com>,
"Yuyang Du" <yuyang.du@intel.com>,
mgalbraith@suse.de,
"Sai Charan Gurrappadi" <sgurrappadi@nvidia.com>,
"Koan-Sin Tan" <freedom.tan@mediatek.com>,
小林敬太 <keita.kobayashi.ym@renesas.com>,
linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v3 11/13] sched/fair: Consider spare capacity in find_idlest_group()
Date: Thu, 18 Aug 2016 14:28:54 +0200 [thread overview]
Message-ID: <20160818122854.GC10153@twins.programming.kicks-ass.net> (raw)
In-Reply-To: <20160818111632.GB27873@e105550-lin.cambridge.arm.com>
On Thu, Aug 18, 2016 at 12:16:33PM +0100, Morten Rasmussen wrote:
> On Tue, Aug 16, 2016 at 03:57:06PM +0200, Vincent Guittot wrote:
> > > @@ -5204,6 +5218,13 @@ find_idlest_group(struct sched_domain *sd, struct task_struct *p,
> > > load = target_load(i, load_idx);
> > >
> > > avg_load += load;
> > > +
> > > + spare_cap = capacity_spare_wake(i, p);
> > > +
> > > + if (spare_cap > max_spare_cap &&
> > > + spare_cap > capacity_of(i) >> 3) {
> >
> > This condition probably needs some descriptions. You're not only
> > looking for max spare capacity but also a significant spare capacity
> > (more than 12.5% of cpu_capacity_orig). Can't this additional test
> > lead to some strange situation where a CPU with more spare capacity
> > will not be selected because of this 12.5% condition whereas another
> > with less spare capacity will be selected because its capacity_orig is
> > lower ?
>
> Right, the reason why I added the 12.5% check is that I thought we
> wouldn't want to pack cpus too aggressively. You are right that we could
> reject a 1024 capacity with a spare capacity of 100 and pick a 512
> capacity cpu with a spare capacity of 65.
You could of course track both.. but complexity. At the very least I
agree with Vincent in that this very much deserves a comment.
> From a latency perspective it might not be a bad idea staying away from
> cpus with a utilization even if they have more capacity available as the
> task is more likely to end up waiting on the rq. For throughput tasks
> you would of course want it the other way around.
(debug) tuning-knob ;-)
> > > @@ -5211,12 +5232,27 @@ find_idlest_group(struct sched_domain *sd, struct task_struct *p,
> > >
> > > if (local_group) {
> > > this_load = avg_load;
> > > - } else if (avg_load < min_load) {
> > > - min_load = avg_load;
> > > - idlest = group;
> > > + this_spare = max_spare_cap;
> > > + } else {
> > > + if (avg_load < min_load) {
> > > + min_load = avg_load;
> > > + idlest = group;
> > > + }
> > > +
> > > + if (most_spare < max_spare_cap) {
> > > + most_spare = max_spare_cap;
> > > + most_spare_sg = group;
> > > + }
> > > }
> > > } while (group = group->next, group != sd->groups);
> > >
> > > + /* Found a significant amount of spare capacity. */
> >
> > It may worth explaining the threshold when it becomes better to choose
> > the most spare group instead of the least loaded group.
>
> Yes. I admit that the threshold is somewhat randomly chosen. Based on a
> few experiments I found that requiring enough spare capacity to fit the
> task completely was too conservative. We would bail out and go with the
> least loaded groups very often, especially for new tasks, despite the
> spare capacity only being slightly too small. Allowing a small degree of
> stuffing of the task seemed better. Choosing the least loaded group
> instead doesn't give any better throughput for the waking task unless it
> has high priority. For overall throughput, the most spare capacity cpus
> should be the better choice.
>
> Should I just add a comment saying that we want to allow a little bit of
> task stuffing to accommodate better for new tasks and have better overall
> throughput, or should we investigate the threshold further?
A comment would certainly be nice..
next prev parent reply other threads:[~2016-08-18 12:49 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-07-25 13:34 [PATCH v3 00/13] sched: Clean-ups and asymmetric cpu capacity support Morten Rasmussen
2016-07-25 13:34 ` [PATCH v3 01/13] sched: Fix power to capacity renaming in comment Morten Rasmussen
2016-07-25 13:34 ` [PATCH v3 02/13] sched/fair: Consistent use of prev_cpu in wakeup path Morten Rasmussen
2016-07-25 13:34 ` [PATCH v3 03/13] sched/fair: Optimize find_idlest_cpu() when there is no choice Morten Rasmussen
2016-07-25 13:34 ` [PATCH v3 04/13] sched/core: Remove unnecessary null-pointer check Morten Rasmussen
2016-08-18 10:56 ` [tip:sched/core] sched/core: Remove unnecessary NULL-pointer check tip-bot for Morten Rasmussen
2016-07-25 13:34 ` [PATCH v3 05/13] sched: Introduce SD_ASYM_CPUCAPACITY sched_domain topology flag Morten Rasmussen
2016-08-15 10:54 ` Peter Zijlstra
2016-08-15 11:43 ` Morten Rasmussen
2016-08-18 10:56 ` [tip:sched/core] sched/core: Clarify SD_flags comment tip-bot for Peter Zijlstra
2016-08-17 8:42 ` [PATCH v3 05/13] sched: Introduce SD_ASYM_CPUCAPACITY sched_domain topology flag Wanpeng Li
2016-08-17 9:23 ` Morten Rasmussen
2016-08-17 9:26 ` Wanpeng Li
2016-08-18 10:56 ` [tip:sched/core] sched/core: " tip-bot for Morten Rasmussen
2016-07-25 13:34 ` [PATCH v3 06/13] sched/core: Pass child domain into sd_init Morten Rasmussen
2016-08-18 10:57 ` [tip:sched/core] sched/core: Pass child domain into sd_init() tip-bot for Morten Rasmussen
2016-07-25 13:34 ` [PATCH v3 07/13] sched: Enable SD_BALANCE_WAKE for asymmetric capacity systems Morten Rasmussen
2016-08-18 10:57 ` [tip:sched/core] sched/core: " tip-bot for Morten Rasmussen
2016-07-25 13:34 ` [PATCH v3 08/13] sched: Store maximum per-cpu capacity in root domain Morten Rasmussen
2016-08-01 18:53 ` Dietmar Eggemann
2016-08-16 12:24 ` Vincent Guittot
2016-08-18 10:58 ` [tip:sched/core] sched/core: Store maximum per-CPU " tip-bot for Dietmar Eggemann
2016-07-25 13:34 ` [PATCH v3 09/13] sched/fair: Let asymmetric cpu configurations balance at wake-up Morten Rasmussen
2016-08-15 13:39 ` Peter Zijlstra
2016-08-15 15:01 ` Morten Rasmussen
2016-08-15 15:10 ` Peter Zijlstra
2016-08-15 15:30 ` Morten Rasmussen
2016-08-18 10:58 ` [tip:sched/core] sched/fair: Let asymmetric CPU " tip-bot for Morten Rasmussen
2016-07-25 13:34 ` [PATCH v3 10/13] sched/fair: Compute task/cpu utilization at wake-up more correctly Morten Rasmussen
2016-08-15 14:23 ` Peter Zijlstra
2016-08-15 15:42 ` Morten Rasmussen
2016-08-18 8:40 ` Morten Rasmussen
2016-08-18 10:24 ` Morten Rasmussen
2016-08-18 11:46 ` Wanpeng Li
2016-08-18 13:45 ` Morten Rasmussen
2016-08-19 1:43 ` Wanpeng Li
2016-08-19 14:03 ` Morten Rasmussen
2016-08-22 1:48 ` Wanpeng Li
2016-08-22 11:29 ` Morten Rasmussen
2016-07-25 13:34 ` [PATCH v3 11/13] sched/fair: Consider spare capacity in find_idlest_group() Morten Rasmussen
2016-08-16 13:57 ` Vincent Guittot
2016-08-18 11:16 ` Morten Rasmussen
2016-08-18 12:28 ` Peter Zijlstra [this message]
2016-07-25 13:34 ` [PATCH v3 12/13] sched: Add per-cpu min capacity to sched_group_capacity Morten Rasmussen
2016-07-25 13:34 ` [PATCH v3 13/13] sched/fair: Avoid pulling tasks from non-overloaded higher capacity groups Morten Rasmussen
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=20160818122854.GC10153@twins.programming.kicks-ass.net \
--to=peterz@infradead.org \
--cc=dietmar.eggemann@arm.com \
--cc=freedom.tan@mediatek.com \
--cc=keita.kobayashi.ym@renesas.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mgalbraith@suse.de \
--cc=mingo@redhat.com \
--cc=morten.rasmussen@arm.com \
--cc=sgurrappadi@nvidia.com \
--cc=vincent.guittot@linaro.org \
--cc=yuyang.du@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;
as well as URLs for NNTP newsgroup(s).