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

[Vincent Guittot <vincent.guittot@linaro.org>]

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 ?

> It is clearly not as optimized for asymmetric capacity systems as it
> could be, but my focus was to not ruin existing behaviour and minimize
> overhead for others. There are a lot of different routes through those
> conditions in the first half of select_task_rq_fair() that aren't
> obvious. I worry that some users depend on them and that I don't
> see/understand all of them.
>
> If people agree on changing things, it is fine with me. I just tried to
> avoid getting the patches shot down on that account ;-)