linux-kernel - Re: [PATCH v2 2/2] [RFC] CPUFreq: Add support for cpu-perf-dependencies

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: <2417d7b5-bc58-fa30-192c-e5991ec22ce0@arm.com>
Date:   Wed, 7 Oct 2020 13:58:12 +0100
From:   Nicola Mazzucato <nicola.mazzucato@....com>
To:     Viresh Kumar <viresh.kumar@...aro.org>
Cc:     linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
        devicetree@...r.kernel.org, linux-pm@...r.kernel.org,
        sudeep.holla@....com, rjw@...ysocki.net, vireshk@...nel.org,
        robh+dt@...nel.org, daniel.lezcano@...aro.org,
        morten.rasmussen@....com, chris.redpath@....com
Subject: Re: [PATCH v2 2/2] [RFC] CPUFreq: Add support for
 cpu-perf-dependencies

Hi Viresh,

performance controls is what is exposed by the firmware through a protocol that
is not capable of describing hardware (say SCMI). For example, the firmware can
tell that the platform has N controls, but it can't say to which hardware they
are "wired" to. This is done in dt, where, for example, we map these controls
to cpus, gpus, etc.

Let's focus on cpus.

Normally we would have N of performance controls (what comes from f/w)
that that correspond to hardware clock/dvfs domains.

However, some firmware implementations might benefit from having finer
grained information about the performance requirements (e.g.
per-CPU) and therefore choose to present M performance controls to the
OS. DT would be adjusted accordingly to "wire" these controls to cpus
or set of cpus.
In this scenario, the f/w will make aggregation decisions based on the
requests it receives on these M controls.

Here we would have M cpufreq policies which do not necessarily reflect the
underlying clock domains, thus some s/w components will underperform
(EAS and thermal, for example).

A real example would be a platform in which the firmware describes the system
having M per-cpu control, and the cpufreq subsystem will have M policies while
in fact these cpus are "performance-dependent" each other (e.g. are in the same
clock domain). This performance dependency information is essential for some
components that take information from the cpufreq policy.

To restore functionality we can use the optional node
'cpu-performance-dependencies' in dt which will provide such dependency
information and we can add a new cpumask 'dependency_cpus' in policy.

Hope it gives some clarity.

Nicola

On 10/6/20 8:19 AM, Viresh Kumar wrote:
> On 24-09-20, 10:53, Nicola Mazzucato wrote:
>> I am seeking some feedback/comments on the following approach.
>>
>> Intro:
>> Info of performance depency for cpus will be beneficial for systems
>> where f/w description of the CPU performance control domain is different
>> from the clock domain, e.g. per-CPU control with multiple CPUs sharing
>> clock, and kernel OSPM s/w components need to take CPU performance
>> dependency into account.
>> Essentially these s/w components will have to be provided with
>> this information from dt and this RFC is presenting a possible way
>> to do so.
> 
> I am not sure I understand what performance control mean here. Can you please
> elaborate a bit more on that ? For example, with current code and understanding,
> a cpufreq policy belongs to a group of CPUs which change their frequency
> together, which also mean that they change their performance level together and
> so I am not able to understand what's going on here. Sorry about that.
> 
> What kind of hardware configuration doesn't work with this ?
>