Re: [Resend][PATCH] cpufreq: conservative: Decrease frequency faster when the timer deferred

[Stratos Karafotis]

On 08/11/2016 10:32 ÏÎ, Viresh Kumar wrote:
> On 8 November 2016 at 12:49, Stratos Karafotis <stratosk@xxxxxxxxxxxx> wrote:
>> I think we shouldn't. That's why the patch first decreases the frequency
>> by n freq steps (where n the number of deferred periods).
>> Then the normal processing takes place.
> 
> The problem that I see is that the new algorithm will reduce the
> frequency even if we are
> on a ramp up phase.
> 
> For example consider this case:
> 
> - We have a special load running, that runs in bursts. i.e. runs for
> some time, lets the CPU idle
> then and then again runs.
> 
> - To run the load properly, we need to ramp up the frequency
> 
> - But the new algorithm can make the frequency stagnant in this case.
> i.e. because of the idle
> period you may want to decrease the frequency by delta A and then the
> regular algorithm may
> want to increase it by same delta A.
> 
> That's why I was asking to adopt this only in the ramp down path.
> 

But this is the supposed behaviour of conservative governor. We want
the CPU to increase the frequency in steps. The patch just resets
the frequency to a lower frequency in case of idle.

For argument's sake, let's assume that the governor timer is never
deferred and runs every sampling period even on completely idle CPU.
And let's assume, for example, a burst load that runs every 100ms
for 20ms. The default sampling rate is also 20ms.
What would conservative do in case of that burst load? It would
increase the frequency by one freq step after 20ms and then it would
decrease the frequency 4 times by one frequency step. Most probably
on the next burst load, the CPU will run on min frequency.

I agree that maybe this is not ideal for performance but maybe this is
how we want conservative governor to work (lazily increase and decrease
frequency).


Regards,
Stratos