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

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: <20161109055537.GA5544@vireshk-i7>
Date:   Wed, 9 Nov 2016 11:25:37 +0530
From:   Viresh Kumar <viresh.kumar@...aro.org>
To:     Stratos Karafotis <stratosk@...aphore.gr>
Cc:     "linux-pm@...r.kernel.org" <linux-pm@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        "Rafael J. Wysocki" <rjw@...ysocki.net>
Subject: Re: [Resend][PATCH] cpufreq: conservative: Decrease frequency faster
 when the timer deferred

On 08-11-16, 21:25, Stratos Karafotis wrote:
> 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.

There are no timers now :)

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

Idle periods are already accounted for while calculating system load by legacy
governors.

And the more and more I think about this, I am inclined towards your patch.
Maybe in a bit different form and commit log.

If we see how the governors were written initially, there were no deferred
timers. And so even if CPUs were idle, we will wake up to adjust the step.

Even if we want to make the behavior similar to that, then also we should
account of missed sampling periods both while decreasing or increasing
frequencies.

@Rafael: What do you think ?

-- 
viresh