All of lore.kernel.org
 help / color / mirror / Atom feed
From: Viresh Kumar <viresh.kumar@linaro.org>
To: Nicola Mazzucato <nicola.mazzucato@arm.com>
Cc: linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org,
	linux-pm@vger.kernel.org, sudeep.holla@arm.com,
	rjw@rjwysocki.net, vireshk@kernel.org, robh+dt@kernel.org,
	daniel.lezcano@linaro.org, morten.rasmussen@arm.com,
	chris.redpath@arm.com
Subject: Re: [PATCH v2 2/2] [RFC] CPUFreq: Add support for cpu-perf-dependencies
Date: Thu, 8 Oct 2020 16:32:41 +0530	[thread overview]
Message-ID: <20201008110241.dcyxdtqqj7slwmnc@vireshk-i7> (raw)
In-Reply-To: <2417d7b5-bc58-fa30-192c-e5991ec22ce0@arm.com>

On 07-10-20, 13:58, Nicola Mazzucato wrote:
> 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).

If the CPUs are in the same clock domain, they must be part of the
same cpufreq policy.

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

Some, but I am still confused :(

Can you give a real example, with exact number of CPUs, how they share
clocks/voltage domains and what else the firmware needs in terms of
performance-domains ? That may make it easier for me to understand it.

-- 
viresh

WARNING: multiple messages have this Message-ID (diff)
From: Viresh Kumar <viresh.kumar@linaro.org>
To: Nicola Mazzucato <nicola.mazzucato@arm.com>
Cc: devicetree@vger.kernel.org, linux-pm@vger.kernel.org,
	vireshk@kernel.org, daniel.lezcano@linaro.org, rjw@rjwysocki.net,
	linux-kernel@vger.kernel.org, robh+dt@kernel.org,
	sudeep.holla@arm.com, chris.redpath@arm.com,
	morten.rasmussen@arm.com, linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v2 2/2] [RFC] CPUFreq: Add support for cpu-perf-dependencies
Date: Thu, 8 Oct 2020 16:32:41 +0530	[thread overview]
Message-ID: <20201008110241.dcyxdtqqj7slwmnc@vireshk-i7> (raw)
In-Reply-To: <2417d7b5-bc58-fa30-192c-e5991ec22ce0@arm.com>

On 07-10-20, 13:58, Nicola Mazzucato wrote:
> 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).

If the CPUs are in the same clock domain, they must be part of the
same cpufreq policy.

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

Some, but I am still confused :(

Can you give a real example, with exact number of CPUs, how they share
clocks/voltage domains and what else the firmware needs in terms of
performance-domains ? That may make it easier for me to understand it.

-- 
viresh

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2020-10-08 11:02 UTC|newest]

Thread overview: 88+ 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 ` Nicola Mazzucato
2020-09-24  9:53 ` [PATCH v2 1/2] dt-bindings: arm: Add devicetree binding for cpu-performance-dependencies Nicola Mazzucato
2020-09-24  9:53   ` Nicola Mazzucato
2020-10-08 13:42   ` Ionela Voinescu
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-09-24  9:53   ` Nicola Mazzucato
2020-10-06  7:19   ` Viresh Kumar
2020-10-06  7:19     ` Viresh Kumar
2020-10-07 12:58     ` Nicola Mazzucato
2020-10-07 12:58       ` Nicola Mazzucato
2020-10-08 11:02       ` Viresh Kumar [this message]
2020-10-08 11:02         ` Viresh Kumar
2020-10-08 15:03         ` Ionela Voinescu
2020-10-08 15:03           ` Ionela Voinescu
2020-10-08 15:57           ` Rafael J. Wysocki
2020-10-08 15:57             ` Rafael J. Wysocki
2020-10-08 17:08             ` Ionela Voinescu
2020-10-08 17:08               ` Ionela Voinescu
2020-10-12 16:06             ` Sudeep Holla
2020-10-12 16:06               ` Sudeep Holla
2020-10-08 16:00           ` Nicola Mazzucato
2020-10-08 16:00             ` Nicola Mazzucato
2020-10-09  5:39             ` Viresh Kumar
2020-10-09  5:39               ` Viresh Kumar
2020-10-09 11:10               ` Nicola Mazzucato
2020-10-09 11:10                 ` Nicola Mazzucato
2020-10-09 11:17                 ` Viresh Kumar
2020-10-09 11:17                   ` Viresh Kumar
2020-10-09 14:01                 ` Rob Herring
2020-10-09 14:01                   ` Rob Herring
2020-10-09 15:28                   ` Nicola Mazzucato
2020-10-09 15:28                     ` Nicola Mazzucato
2020-10-12  4:19                     ` Viresh Kumar
2020-10-12  4:19                       ` Viresh Kumar
2020-10-12 10:22                   ` Lukasz Luba
2020-10-12 10:22                     ` Lukasz Luba
2020-10-12 10:50                     ` Rafael J. Wysocki
2020-10-12 10:50                       ` Rafael J. Wysocki
2020-10-12 11:05                       ` Lukasz Luba
2020-10-12 11:05                         ` Lukasz Luba
2020-10-12 10:59                     ` Ionela Voinescu
2020-10-12 10:59                       ` Ionela Voinescu
2020-10-12 13:48                       ` Lukasz Luba
2020-10-12 13:48                         ` Lukasz Luba
2020-10-12 16:30                         ` Ionela Voinescu
2020-10-12 16:30                           ` Ionela Voinescu
2020-10-12 18:19                           ` Lukasz Luba
2020-10-12 18:19                             ` Lukasz Luba
2020-10-12 22:01                             ` Ionela Voinescu
2020-10-12 22:01                               ` Ionela Voinescu
2020-10-13 11:53                               ` Rafael J. Wysocki
2020-10-13 11:53                                 ` Rafael J. Wysocki
2020-10-13 12:39                                 ` Ionela Voinescu
2020-10-13 12:39                                   ` Ionela Voinescu
2020-10-15 15:56                                   ` Rafael J. Wysocki
2020-10-15 15:56                                     ` Rafael J. Wysocki
2020-10-15 18:38                                     ` Ionela Voinescu
2020-10-15 18:38                                       ` Ionela Voinescu
2020-10-12 13:59                     ` Rob Herring
2020-10-12 13:59                       ` Rob Herring
2020-10-12 16:02                     ` Sudeep Holla
2020-10-12 16:02                       ` Sudeep Holla
2020-10-12 15:54                   ` Sudeep Holla
2020-10-12 15:54                     ` Sudeep Holla
2020-10-12 15:49               ` Sudeep Holla
2020-10-12 15:49                 ` Sudeep Holla
2020-10-12 16:52                 ` Ionela Voinescu
2020-10-12 16:52                   ` Ionela Voinescu
2020-10-12 17:18                   ` Lukasz Luba
2020-10-12 17:18                     ` Lukasz Luba
2020-10-14  4:25                     ` Viresh Kumar
2020-10-14  4:25                       ` Viresh Kumar
2020-10-14  9:11                       ` Lukasz Luba
2020-10-14  9:11                         ` Lukasz Luba
2020-10-19  8:50                       ` Nicola Mazzucato
2020-10-19  8:50                         ` Nicola Mazzucato
2020-10-19  9:46                         ` Viresh Kumar
2020-10-19  9:46                           ` Viresh Kumar
2020-10-19 13:36                           ` Nicola Mazzucato
2020-10-19 13:36                             ` Nicola Mazzucato
2020-10-20 10:48                             ` Viresh Kumar
2020-10-20 10:48                               ` Viresh Kumar
2020-10-13 13:53               ` Lukasz Luba
2020-10-13 13:53                 ` Lukasz Luba
2020-10-14  4:20                 ` Viresh Kumar
2020-10-14  4:20                   ` Viresh Kumar

Reply instructions:

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:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20201008110241.dcyxdtqqj7slwmnc@vireshk-i7 \
    --to=viresh.kumar@linaro.org \
    --cc=chris.redpath@arm.com \
    --cc=daniel.lezcano@linaro.org \
    --cc=devicetree@vger.kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=morten.rasmussen@arm.com \
    --cc=nicola.mazzucato@arm.com \
    --cc=rjw@rjwysocki.net \
    --cc=robh+dt@kernel.org \
    --cc=sudeep.holla@arm.com \
    --cc=vireshk@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.