Re: [PATCH] cpufreq: schedutil: add up/down frequency transition rate limits

[Vincent Guittot]

On 21 November 2016 at 15:37, Juri Lelli <Juri.Lelli@xxxxxxx> wrote:
> On 21/11/16 15:17, Peter Zijlstra wrote:
>> On Mon, Nov 21, 2016 at 01:53:08PM +0000, Juri Lelli wrote:
>> > On 21/11/16 13:26, Peter Zijlstra wrote:
>>
>> > > So the limited decay would be the dominant factor in ramp-up time,
>> > > leaving the regular PELT period the dominant factor for ramp-down.
>> > >
>> >
>> > Hmmm, AFAIU the limited decay will help not forgetting completely the
>> > contribution of tasks that sleep for a long time, but it won't modify
>> > the actual ramp-up of the signal. So, for new tasks we will need to play
>> > with a sensible initial value (trading off perf and power as usual).
>>
>> Oh, you mean ramp-up for bright spanking new tasks? I forgot the
>> details, but I think we can fudge the 'history' such that those too ramp
>> up quickly.
>>
>
> Right. I think Vincent had some ideas on this front already.

You are probably referring to some properties linked to how the PELT
signal is evolving. As an example, an increase of 100 pf the
utilization during the running phase means that we have for sure run
for more than 5ms. This could probably used such kind of properties
when estimating the utilization level of the task or the CPU

>
>> > > (Note that the decay limit would only be applied on the per-task signal,
>> > > not the accumulated signal.)
>> > >
>> >
>> > Right, and since schedutil consumes the latter, we could still suffer
>> > from too frequent frequency switch events I guess (this is where the
>> > down threshold thing came as a quick and dirty fix). Maybe we can think
>> > of some smoothing applied to the accumulated signal, or make it decay
>> > slower (don't really know what this means in practice, though :) ?
>>
>> Not sure I follow. So by limiting decay to the task value, the moment we
>> add it back to the accumulated signal (wakeup), the accumulated signal
>> jumps up quickly and ramp-up is achieved.
>>
>
> This is true, but it seems that this potentially spiky behaviour
> (which in general depends on tasks composition and periodicity) might
> affect power savings (as in you don't generally want to switch between
> high and low freqs too often). So that's why I was just thinking that
> some sort of smoothing applied to the signal schedutil uses might help.