Message-ID: <CAKfTPtBgu2TUuk+J=cHyw=eJbGyt24nMMMmdwB8NyVHAH06hOA@mail.gmail.com>
Date:	Tue, 24 May 2016 15:52:00 +0200
From:	Vincent Guittot <vincent.guittot@...aro.org>
To:	Morten Rasmussen <morten.rasmussen@....com>
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 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:
>> >> > On Tue, May 24, 2016 at 11:10:28AM +0200, Vincent Guittot wrote:
>> >> >> On 23 May 2016 at 12:58, Morten Rasmussen <morten.rasmussen@....com> 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?
>>
>> My point is that there is some wake up case where we don't care about
>> the capacity and utilization of cpus even for cross capacity migration
>> and we will never take benefit of this fast path.
>> You have added an extra check for setting want_affine in patch 9 which
>> uses capacity and utilization of cpu to disable this fast path when a
>> task needs more capacity than available. Can't you use this function
>> to disable the want_affine for cross-capacity migration situation that
>> cares of the capacity and need the full scan of sched_domain but keep
>> it enable for other cases ?
>
> 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.

Powered by blists - more mailing lists