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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 22 Nov 2016 10:27:40 +0100
From:   Vincent Guittot <vincent.guittot@...aro.org>
To:     Juri Lelli <Juri.Lelli@....com>
Cc:     Peter Zijlstra <peterz@...radead.org>,
        Viresh Kumar <viresh.kumar@...aro.org>,
        Rafael Wysocki <rjw@...ysocki.net>,
        Ingo Molnar <mingo@...hat.com>,
        "linaro-kernel@...ts.linaro.org" <linaro-kernel@...ts.linaro.org>,
        "linux-pm@...r.kernel.org" <linux-pm@...r.kernel.org>,
        linux-kernel <linux-kernel@...r.kernel.org>,
        Robin Randhawa <robin.randhawa@....com>,
        Steve Muckle <smuckle.linux@...il.com>,
        Todd Kjos <tkjos@...gle.com>,
        Morten Rasmussen <morten.rasmussen@....com>
Subject: Re: [PATCH] cpufreq: schedutil: add up/down frequency transition rate limits

On 21 November 2016 at 15:37, Juri Lelli <Juri.Lelli@....com> 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.