linux-kernel - Re: [PATCH 1/8] cpufreq: allow drivers to flag custom support for freq invariance

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: <389dd87f-fed0-e4ea-81f3-5491fd2a54d1@arm.com>
Date:   Mon, 6 Jul 2020 14:14:47 +0200
From:   Dietmar Eggemann <dietmar.eggemann@....com>
To:     Ionela Voinescu <ionela.voinescu@....com>,
        Viresh Kumar <viresh.kumar@...aro.org>
Cc:     "Rafael J. Wysocki" <rafael@...nel.org>,
        "Rafael J. Wysocki" <rjw@...ysocki.net>,
        Catalin Marinas <catalin.marinas@....com>,
        Sudeep Holla <sudeep.holla@....com>,
        Will Deacon <will@...nel.org>,
        Russell King - ARM Linux <linux@...linux.org.uk>,
        Valentin Schneider <valentin.schneider@....com>,
        Ingo Molnar <mingo@...hat.com>,
        Peter Zijlstra <peterz@...radead.org>,
        Linux PM <linux-pm@...r.kernel.org>,
        Linux ARM <linux-arm-kernel@...ts.infradead.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 1/8] cpufreq: allow drivers to flag custom support for
 freq invariance

On 02/07/2020 13:44, Ionela Voinescu wrote:
> Hi,
> 
> On Thursday 02 Jul 2020 at 08:28:18 (+0530), Viresh Kumar wrote:
>> On 01-07-20, 18:05, Rafael J. Wysocki wrote:
>>> On Wed, Jul 1, 2020 at 3:33 PM Ionela Voinescu <ionela.voinescu@....com> wrote:
>>>> On Wednesday 01 Jul 2020 at 16:16:17 (+0530), Viresh Kumar wrote:

[...]

>> There can be other reasons which we aren't able to imagine at this
>> point of time.
>>
> 
> But I understand both the points you and Rafael raised so it's obvious
> that a 'opt in' flag would be the better option.

Why can't we just move the arch_set_freq_scale() call from cpufreq
driver to cpufreq core w/o introducing a FIE related driver flag?

Current scenario for Frequency Invariance Engine (FIE) on arm/arm64.

+------------------------------+       +------------------------------+
|                              |       |                              |
| cpufreq core:                |       | arch: (arm, arm64)           |

|                              |       |                              |
| weak arch_set_freq_scale() {}|       |                              |
|                              |       |                              |
+------------------------------+       |                              |
                                       |                              |
+------------------------------+       |                              |
|                              |       |                              |
| cpufreq driver:              |       |                              |
|                            +-----------> arch_set_freq_scale()      |
|                              |       |   {                          |
+------------------------------+       |      if (use counters)       |
                                       |        return;               |
+------------------------------+       |      ...                     |
|                              |       |   }                          |
| task scheduler:              |       |                              |
|                            +-----------> arch_scale_freq_tick()*    |
|                              |       |   {                          |

|                              |       |      if (!use counters)      |
|                              |       |        return;               |
|                              |       |      ...                     |
|                              |       |   }                          |
+------------------------------+       +------------------------------+

* defined as topology_scale_freq_tick() in arm64

Only Arm/Arm64 defines arch_set_freq_scale() to get the 'legacy' CPUfreq
based FIE. This would still be the case when we move
arch_set_freq_scale() from individual cpufreq drivers to cpufreq core.

Arm64 is the only arch which has to runtime-choose between two different
FIEs. This is currently done by bailing out early in one of the FIE
functions based on 'use counters'.

X86 (and others) will continue to not define arch_set_freq_scale().

The issue with CONFIG_BL_SWITCHER (vexpress-spc-cpufreq.c) could be
solved arm/arm64 internally (arch_topology.c) by putting
arch_set_freq_scale() under a !CONFIG_BL_SWITCHER guard.
I doubt that there are any arm bL systems out there running it. At least
I'm not aware of any complaints due to missing FIE support in bl
switcher setups so far.