From: Morten Rasmussen <morten.rasmussen@arm.com>
To: Vincent Guittot <vincent.guittot@linaro.org>
Cc: Peter Zijlstra <peterz@infradead.org>,
"mingo@redhat.com" <mingo@redhat.com>,
Dietmar Eggemann <dietmar.eggemann@arm.com>,
Yuyang Du <yuyang.du@intel.com>,
mgalbraith@suse.de, linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 06/16] sched: Disable WAKE_AFFINE for asymmetric configurations
Date: Tue, 7 Jun 2016 17:50:46 +0100 [thread overview]
Message-ID: <20160607165045.GC9187@e105550-lin.cambridge.arm.com> (raw)
In-Reply-To: <CAKfTPtBfftVmW8NDcAB=KnH_iWiEoH9ovLCpejapsv9znrfbaw@mail.gmail.com>
On Thu, May 26, 2016 at 08:45:03AM +0200, Vincent Guittot wrote:
> On 25 May 2016 at 11:12, Morten Rasmussen <morten.rasmussen@arm.com> wrote:
> > On Tue, May 24, 2016 at 05:53:27PM +0200, Vincent Guittot wrote:
> >> On 24 May 2016 at 17:02, Morten Rasmussen <morten.rasmussen@arm.com> wrote:
> >> > On Tue, May 24, 2016 at 03:52:00PM +0200, Vincent Guittot wrote:
> >> >> On 24 May 2016 at 15:36, Morten Rasmussen <morten.rasmussen@arm.com> wrote:
> >> >> > On Tue, May 24, 2016 at 03:27:05PM +0200, Vincent Guittot wrote:
> >> >> >> On 24 May 2016 at 15:16, Morten Rasmussen <morten.rasmussen@arm.com> wrote:
> >> >> >> > On Tue, May 24, 2016 at 02:12:38PM +0200, Vincent Guittot wrote:
> >> >> >> >> On 24 May 2016 at 12:29, Morten Rasmussen <morten.rasmussen@arm.com> wrote:
>
> [snip]
>
> >> >> > It is not clear to me what the other cases are. What kind of cases do
> >> >> > you have in mind?
> >> >>
> >> >> As an example, you have a task A that have to be on a big CPU because
> >> >> of the requirement of compute capacity, that wakes up a task B that
> >> >> can run on any cpu according to its utilization. The fast wake up path
> >> >> is fine for task B whatever prev cpu is.
> >> >
> >> > In that case, we will take always take fast path (select_idle_sibling())
> >> > for task B if wake_wide() allows it, which should be fine.
> >>
> >> Even if want_affine is set, the wake up of task B will not use the fast path.
> >> The affine_sd will not be set because the sched_domain, which have
> >> both cpus, will not have the SD_WAKE_AFFINE flag according to this
> >> patch, isn't it ?
> >> So task B can't use the fast path whereas nothing prevent him to take
> >> benefit of it
> >>
> >> Am I missing something ?
> >
> > No, I think you are right. Very good point. The cpumask test with
> > sched_domain_span() will of cause return false. So yes, in this case the
> > slow path is taken. It isn't wrong as such, just slower for asymmetric
> > capacity systems :-)
> >
>
> So, I still don't see why the function wake_cap that is introduce by
> patch 9 can't be used for testing cross capacity migration at wake up
> ?
> The only reason for which we would like to skip fast wake up path for
> cross capacity migration, is whether the task needs more capacity than
> the capacity of cpu or prev_cpu. You already do that for prev_cpu,
> can't you add same test for cpu ?
I think I finally see what you mean. Thanks for your patience :-)
It should be safe to let wake_affine be cross-capacity as long as we
only take the fast path when both prev_cpu and this_cpu have sufficient
capacity for the task. select_idle_sibling() can never end up looking at
cpus with different capacities than those of this_cpu and prev_cpu.
I will give that a try. I have a few ideas on how it can extended to use
the fast path in a few additional cases as well.
next prev parent reply other threads:[~2016-06-07 16:49 UTC|newest]
Thread overview: 61+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-05-23 10:58 [PATCH 00/16] sched: Clean-ups and asymmetric cpu capacity support Morten Rasmussen
2016-05-23 10:58 ` [PATCH 01/16] sched: Fix power to capacity renaming in comment Morten Rasmussen
2016-05-23 10:58 ` [PATCH 02/16] sched/fair: Consistent use of prev_cpu in wakeup path Morten Rasmussen
2016-06-01 19:49 ` Peter Zijlstra
2016-05-23 10:58 ` [PATCH 03/16] sched/fair: Disregard idle task wakee_flips in wake_wide Morten Rasmussen
2016-05-23 11:12 ` Mike Galbraith
2016-05-23 12:00 ` Morten Rasmussen
2016-05-23 13:00 ` Mike Galbraith
2016-05-23 14:10 ` Morten Rasmussen
2016-05-23 15:42 ` Mike Galbraith
2016-05-23 23:17 ` Yuyang Du
2016-05-23 23:04 ` Yuyang Du
2016-06-01 19:57 ` Peter Zijlstra
2016-06-02 8:05 ` Peter Zijlstra
2016-06-07 12:08 ` Morten Rasmussen
2016-05-23 10:58 ` [PATCH 04/16] sched/fair: Optimize find_idlest_cpu() when there is no choice Morten Rasmussen
2016-05-24 6:29 ` Mike Galbraith
2016-05-24 8:05 ` Morten Rasmussen
2016-05-24 8:12 ` Mike Galbraith
2016-06-01 19:59 ` Peter Zijlstra
2016-06-07 14:25 ` Morten Rasmussen
2016-05-23 10:58 ` [PATCH 05/16] sched: Introduce SD_ASYM_CPUCAPACITY sched_domain topology flag Morten Rasmussen
2016-05-23 10:58 ` [PATCH 06/16] sched: Disable WAKE_AFFINE for asymmetric configurations Morten Rasmussen
2016-05-24 9:10 ` Vincent Guittot
2016-05-24 10:29 ` Morten Rasmussen
2016-05-24 12:12 ` Vincent Guittot
2016-05-24 13:16 ` Morten Rasmussen
2016-05-24 13:27 ` Vincent Guittot
2016-05-24 13:36 ` Morten Rasmussen
2016-05-24 13:52 ` Vincent Guittot
2016-05-24 15:02 ` Morten Rasmussen
2016-05-24 15:53 ` Vincent Guittot
2016-05-25 9:12 ` Morten Rasmussen
2016-05-26 6:45 ` Vincent Guittot
2016-06-07 16:50 ` Morten Rasmussen [this message]
2016-05-23 10:58 ` [PATCH 07/16] sched: Make SD_BALANCE_WAKE a topology flag Morten Rasmussen
2016-05-24 23:52 ` Yuyang Du
2016-05-25 9:27 ` Morten Rasmussen
2016-06-01 20:18 ` Peter Zijlstra
2016-06-08 8:45 ` Morten Rasmussen
2016-05-23 10:58 ` [PATCH 08/16] sched: Store maximum per-cpu capacity in root domain Morten Rasmussen
2016-05-23 10:58 ` [PATCH 09/16] sched/fair: Let asymmetric cpu configurations balance at wake-up Morten Rasmussen
2016-05-24 0:04 ` Yuyang Du
2016-05-24 8:10 ` Morten Rasmussen
2016-05-24 7:03 ` Mike Galbraith
2016-05-24 7:15 ` Mike Galbraith
2016-05-25 6:57 ` Wanpeng Li
2016-05-25 9:49 ` Morten Rasmussen
2016-05-25 10:29 ` Wanpeng Li
2016-05-25 10:54 ` Morten Rasmussen
2016-05-25 11:18 ` Wanpeng Li
2016-06-02 14:21 ` Peter Zijlstra
2016-06-08 11:29 ` Morten Rasmussen
2016-06-08 14:36 ` Peter Zijlstra
2016-05-23 10:58 ` [PATCH 10/16] sched/fair: Compute task/cpu utilization at wake-up more correctly Morten Rasmussen
2016-05-23 10:58 ` [PATCH 11/16] sched/fair: Consider spare capacity in find_idlest_group() Morten Rasmussen
2016-05-23 10:58 ` [PATCH 12/16] sched: Add per-cpu max capacity to sched_group_capacity Morten Rasmussen
2016-05-23 10:58 ` [PATCH 13/16] sched/fair: Avoid pulling tasks from non-overloaded higher capacity groups Morten Rasmussen
2016-05-23 10:58 ` [PATCH 14/16] arm: Set SD_ASYM_CPUCAPACITY for big.LITTLE platforms Morten Rasmussen
2016-05-23 10:58 ` [PATCH 15/16] arm: Set SD_BALANCE_WAKE flag for asymmetric capacity systems Morten Rasmussen
2016-05-23 10:58 ` [PATCH 16/16] arm: Update arch_scale_cpu_capacity() to reflect change to define 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=20160607165045.GC9187@e105550-lin.cambridge.arm.com \
--to=morten.rasmussen@arm.com \
--cc=dietmar.eggemann@arm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mgalbraith@suse.de \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--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).