linux-kernel - Re: [PATCH 06/16] sched: Disable WAKE_AFFINE for asymmetric configurations

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20160607165045.GC9187@e105550-lin.cambridge.arm.com>
Date:	Tue, 7 Jun 2016 17:50:46 +0100
From:	Morten Rasmussen <morten.rasmussen@....com>
To:	Vincent Guittot <vincent.guittot@...aro.org>
Cc:	Peter Zijlstra <peterz@...radead.org>,
	"mingo@...hat.com" <mingo@...hat.com>,
	Dietmar Eggemann <dietmar.eggemann@....com>,
	Yuyang Du <yuyang.du@...el.com>, mgalbraith@...e.de,
	linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 06/16] sched: Disable WAKE_AFFINE for asymmetric
 configurations

On Thu, May 26, 2016 at 08:45:03AM +0200, Vincent Guittot wrote:
> On 25 May 2016 at 11:12, Morten Rasmussen <morten.rasmussen@....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@....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@....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@....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@....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.