Re: [PATCH RFC 2/5] sched/fair: Skip frequency update if CPU about to idle

[Vincent Guittot]

Hi Joel,

On 4 November 2017 at 06:44, Joel Fernandes <joelaf@xxxxxxxxxx> wrote:
> On Wed, Nov 1, 2017 at 12:35 PM, Steve Muckle <smuckle@xxxxxxxxxx> wrote:
>> On 10/30/2017 12:02 PM, Joel Fernandes wrote:
>>>>
>>>> Also, this more looks like a policy decision. Will it be better to
>>>> put that directly into schedutil? Like this:
>>>>
>>>>          if (cpu_idle())
>>>>                  "Don't change the freq";
>>>>
>>>> Will something like that work?
>>>
>>>
>>> I thought about this and I think it wont work very well. In the
>>> dequeue path we're still running the task being dequeued so the CPU is
>>> not yet idle. What is needed here IMO is a notion that the CPU is
>>> possibly about to idle and we can get predict that from the dequeue
>>> path of the CFS class.
>>>
>>> Also just looking at whether the CPU is currently idle or not in the
>>> governor doesn't help to differentiate between say the dequeue path /
>>> tick path. Both of which can occur when the CPU is not idle.
>>>
>>> Any thoughts about this?
>>
>>
>> Also if it really is the case that this bit of policy is universally
>> desirable, I'd think it is better to do this in the scheduler and avoid a
>> needless trip through a fn pointer out to schedutil for performance reasons.
>
> I agree.
>
> Peter, what do you think? Are you Ok with the approach of this patch
> (preventing of the cpufreq update call during dequeue)?

I'm not really convinced that we should do change OPP at dequeue.
Although i agree that it makes perfect sense to prevent increasing OPP
just before going idle for mp3 playback, i'm not sure that this is
always the case especially for performance oriented use case because
we delay the OPP increase and as a result the responsiveness of the
CPU
In  fact this decision really depends about how long we are going to
sleep. If the cpu will wakes up in few ms, it's worth already
increasing the frequency when utilization is above the threshold
because it will not decreases enough to go back to lower OPP. At the
opposite, if the cpu will not wake up shortly skipping OPP change can
make sense.

Regarding the reduction of the number of OPP changes, will the
util_est feature provide the same amount of reduction by directly
providing the estimated max utilization ?

Just to say that IMHO skipping or not OPP change at dequeue is a
policy decision and not a generic one

>
> thanks,
>
> - Joel