linux-kernel - Re: cpuidle and cpufreq coupling?

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:   Thu, 20 Jul 2017 17:11:01 -0700
From:   Vikram Mulukutla <markivx@...eaurora.org>
To:     Florian Fainelli <f.fainelli@...il.com>,
        Peter Zijlstra <peterz@...radead.org>,
        "Rafael J. Wysocki" <rafael@...nel.org>
Cc:     Viresh Kumar <viresh.kumar@...aro.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Linux PM <linux-pm@...r.kernel.org>,
        "Rafael J. Wysocki" <rjw@...ysocki.net>,
        Markus Mayer <code@...yer.net>,
        Daniel Lezcano <daniel.lezcano@...aro.org>
Subject: Re: cpuidle and cpufreq coupling?

On 7/20/2017 3:56 PM, Florian Fainelli wrote:
> On 07/20/2017 07:45 AM, Peter Zijlstra wrote:

<snip>

>> 
>> Can your ARM part change OPP without scheduling? Because (for obvious
>> reasons) the idle thread is not supposed to block.
> 
> I think it should be able to do that, but I am not sure that if I went
> through the cpufreq API it would be that straight forward so I may have
> to re-implement some of the frequency scaling logic outside of cpufreq
> (or rather make the low-level parts some kind of library I guess).
> 

I think I can safely mention that some of our non-upstream idle drivers
in the past have invoked low level clock drivers to atomically switch
CPUs to low frequency OPPs, with no interaction whatsoever with cpufreq.
It was maintainable since both the idle and clock drivers were
qcom-specific. However this is no longer necessary in recent designs and
I really hope we never need to do this again...

We didn't have to do a voltage switch and just PLL or mux
work so this was doable. I'm guessing your atomic switching also allows
voltage reduction?

If your architecture allows another CPU to change the entering-idle 
CPU's
frequency, synchronization will be necessary as well - this is where it
can get a bit tricky.

Thanks,
Vikram