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]

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

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.

> > > (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.