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: <20161121145947.GQ24383@e106622-lin>
Date:   Mon, 21 Nov 2016 14:59:47 +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:43, Peter Zijlstra wrote:
> On Mon, Nov 21, 2016 at 02:37:27PM +0000, Juri Lelli wrote:
> > On 21/11/16 15:17, Peter Zijlstra wrote:
> 
> > > 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.
> 
> Hurm.. so during LPC it was said that fast ramp-up was desired. Note
> that we'll not ramp down this fast, the accumulated signal will decay
> slowly as per blocked-load PELT rules. So only ramp-up is spiky, but
> that is what was desired AFAIU.
> 

Yep, fast ramp-up is quite crucial I'd say. And it's also true that we
should in theory already ramp-down slower. My worries originate mostly
from our experience with Android devices, for which we ended up
introducing thresholds as per subject of this thread. But it's also true
that the landscape it's different there (e.g., slightly different
governor, different utilization signal, etc.), so I guess we should now
re-evaluate things in light of what we discussed here and at LPC.