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] [day] [month] [year] [list]

Date:   Thu, 20 Jul 2017 17:30:38 -0700
From:   Florian Fainelli <f.fainelli@...il.com>
To:     Vikram Mulukutla <markivx@...eaurora.org>,
        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 07/20/2017 05:11 PM, Vikram Mulukutla wrote:
> 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...

Yes same here, this is for a past generation product, current generation
has a smarter design that so far does not require that.

> 
> 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?

Correct there is a voltage reduction occurring which is largely under
control of a separate MCU/firmware.

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

That is a very good point, the frequency scaling is not per-CPU but for
the entire CPU complex (up to 4 cores) so that might indeed be a problem.

Thanks!
-- 
Florian