Re: [PATCH v3 10/13] sched/fair: Compute task/cpu utilization at wake-up more correctly

From: Wanpeng Li <kernellwp@gmail.com>
To: Morten Rasmussen <morten.rasmussen@arm.com>
Cc: "Peter Zijlstra" <peterz@infradead.org>,
	"Ingo Molnar" <mingo@redhat.com>,
	"Dietmar Eggemann" <dietmar.eggemann@arm.com>,
	"Yuyang Du" <yuyang.du@intel.com>,
	"Vincent Guittot" <vincent.guittot@linaro.org>,
	"Mike Galbraith" <mgalbraith@suse.de>,
	sgurrappadi@nvidia.com, "Koan-Sin Tan" <freedom.tan@mediatek.com>,
	小林敬太 <keita.kobayashi.ym@renesas.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v3 10/13] sched/fair: Compute task/cpu utilization at wake-up more correctly
Date: Mon, 22 Aug 2016 09:48:19 +0800	[thread overview]
Message-ID: <CANRm+CxLiSy2JEohZ2iGNbg4kjJpR-5xS9dvzmxvoBHRHBJL_Q@mail.gmail.com> (raw)
In-Reply-To: <20160819140307.GA25262@e105550-lin.cambridge.arm.com>

2016-08-19 22:03 GMT+08:00 Morten Rasmussen <morten.rasmussen@arm.com>:
> On Fri, Aug 19, 2016 at 09:43:00AM +0800, Wanpeng Li wrote:
>> 2016-08-18 21:45 GMT+08:00 Morten Rasmussen <morten.rasmussen@arm.com>:
>> > I assume you are referring to using task_util_peak() instead of
>> > task_util() in wake_cap()?
>>
>> Yes.
>>
>> >
>> > The peak value should never exceed the util_avg accumulated by the task
>> > last time it ran. So any spike has to be caused by the task accumulating
>> > more utilization last time it ran. We don't know if it a spike or a more
>>
>> I see.
>>
>> > permanent change in behaviour, so we have to guess. So a spike on an
>> > asymmetric system could cause us to disable wake affine in some
>> > circumstances (either prev_cpu or waker cpu has to be low compute
>> > capacity) for the following wake-up.
>> >
>> > SMP should be unaffected as we should bail out on the previous
>> > condition.
>>
>> Why capacity_orig instead of capacity since it is checked each time
>> wakeup and maybe rt class/interrupt have already occupied many cpu
>> utilization.
>
> We could switch to capacity for this condition if we also change the
> spare capacity evaluation in find_idlest_group() to do the same. It
> would open up for SMP systems to take find_idlest_group() route if the
> SD_BALANCE_WAKE flag is set.
>
> The reason why I have avoided capacity and used capacity_orig instead
> is that in previous discussions about scheduling behaviour under
> rt/dl/irq pressure it has been clear to me whether we want to move tasks
> away from cpus with capacity < capacity_orig or not. The choice depends
> on the use-case.
>
> In some cases taking rt/dl/irq pressure into account is more complicated
> as we don't know the capacities available in a sched_group without
> iterating over all the cpus. However, I don't think it would complicate
> these patches. It is more a question whether everyone are happy with
> additional conditions in their wake-up path. I guess we could make it a
> sched_feature if people are interested?
>
> In short, I used capacity_orig to play it safe ;-)

Actually you mixed capacity_orig and capacity when evaluating max spare cap.

Regards,
Wanpeng Li