From: Nicola Mazzucato <firstname.lastname@example.org>
To: Viresh Kumar <email@example.com>
Cc: firstname.lastname@example.org, email@example.com,
firstname.lastname@example.org, email@example.com, firstname.lastname@example.org,
Subject: Re: [PATCH v2 2/2] [RFC] CPUFreq: Add support for cpu-perf-dependencies
Date: Wed, 7 Oct 2020 13:58:12 +0100 [thread overview]
Message-ID: <email@example.com> (raw)
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.
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.
>> 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 ?
linux-arm-kernel mailing list
next prev parent reply other threads:[~2020-10-07 12:58 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-24 9:53 [PATCH v2 0/2] CPUFreq: Add support for cpu performance dependencies Nicola Mazzucato
2020-09-24 9:53 ` [PATCH v2 1/2] dt-bindings: arm: Add devicetree binding for cpu-performance-dependencies Nicola Mazzucato
2020-10-08 13:42 ` Ionela Voinescu
2020-09-24 9:53 ` [PATCH v2 2/2] [RFC] CPUFreq: Add support for cpu-perf-dependencies Nicola Mazzucato
2020-10-06 7:19 ` Viresh Kumar
2020-10-07 12:58 ` Nicola Mazzucato [this message]
2020-10-08 11:02 ` Viresh Kumar
2020-10-08 15:03 ` Ionela Voinescu
2020-10-08 15:57 ` Rafael J. Wysocki
2020-10-08 17:08 ` Ionela Voinescu
2020-10-12 16:06 ` Sudeep Holla
2020-10-08 16:00 ` Nicola Mazzucato
2020-10-09 5:39 ` Viresh Kumar
2020-10-09 11:10 ` Nicola Mazzucato
2020-10-09 11:17 ` Viresh Kumar
2020-10-09 14:01 ` Rob Herring
2020-10-09 15:28 ` Nicola Mazzucato
2020-10-12 4:19 ` Viresh Kumar
2020-10-12 10:22 ` Lukasz Luba
2020-10-12 10:50 ` Rafael J. Wysocki
2020-10-12 11:05 ` Lukasz Luba
2020-10-12 10:59 ` Ionela Voinescu
2020-10-12 13:48 ` Lukasz Luba
2020-10-12 16:30 ` Ionela Voinescu
2020-10-12 18:19 ` Lukasz Luba
2020-10-12 22:01 ` Ionela Voinescu
2020-10-13 11:53 ` Rafael J. Wysocki
2020-10-13 12:39 ` Ionela Voinescu
2020-10-15 15:56 ` Rafael J. Wysocki
2020-10-15 18:38 ` Ionela Voinescu
2020-10-12 13:59 ` Rob Herring
2020-10-12 16:02 ` Sudeep Holla
2020-10-12 15:54 ` Sudeep Holla
2020-10-12 15:49 ` Sudeep Holla
2020-10-12 16:52 ` Ionela Voinescu
2020-10-12 17:18 ` Lukasz Luba
2020-10-14 4:25 ` Viresh Kumar
2020-10-14 9:11 ` Lukasz Luba
2020-10-19 8:50 ` Nicola Mazzucato
2020-10-19 9:46 ` Viresh Kumar
2020-10-19 13:36 ` Nicola Mazzucato
2020-10-20 10:48 ` Viresh Kumar
2020-10-13 13:53 ` Lukasz Luba
2020-10-14 4:20 ` Viresh Kumar
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).