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

[Morten Rasmussen]

On Tue, May 24, 2016 at 02:12:38PM +0200, Vincent Guittot wrote:
> On 24 May 2016 at 12:29, Morten Rasmussen <morten.rasmussen@xxxxxxx> wrote:
> > On Tue, May 24, 2016 at 11:10:28AM +0200, Vincent Guittot wrote:
> >> On 23 May 2016 at 12:58, Morten Rasmussen <morten.rasmussen@xxxxxxx> wrote:
> >> > If the system has cpu of different compute capacities (e.g. big.LITTLE)
> >> > let affine wakeups be constrained to cpus of the same type.
> >>
> >> Can you explain why you don't want wake affine with cpus with
> >> different compute capacity ?
> >
> > I should have made the overall idea a bit more clear. The idea is to
> > deal with cross-capacity migrations in the find_idlest_{group, cpu}{}
> > path so we don't have to touch select_idle_sibling().
> > select_idle_sibling() is critical for wake-up latency, and I'm assumed
> > that people wouldn't like adding extra overhead in there to deal with
> > capacity and utilization.
> 
> So this means that we will never use the quick path of
> select_idle_sibling for cross capacity migration but always the one
> with extra overhead?

Yes. select_idle_sibling() is only used to choose among equal capacity
cpus (capacity_orig).

> Patch 9 adds more tests for enabling wake_affine path. Can't it also
> be used for cross capacity migration ? so we can use wake_affine if
> the task or the cpus (even with different capacity) doesn't need this
> extra overhead

The test in patch 9 is to determine whether we are happy with the
capacity of the previous cpu, or we should go look for one with more
capacity. I don't see how we can use select_idle_sibling() unmodified
for sched domains containing cpus of different capacity to select an
appropriate cpu. It is just picking an idle cpu, it might have high
capacity or low, it wouldn't care.

How would you avoid the overhead of checking capacity and utilization of
the cpus and still pick an appropriate cpu?