linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Leo Yan <leo.yan@linaro.org>
To: Sudeep Holla <sudeep.holla@arm.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	"Rafael J. Wysocki" <rafael@kernel.org>,
	Vincent Guittot <vincent.guittot@linaro.org>,
	Bryan O'Donoghue <bryan.odonoghue@linaro.org>,
	linux-kernel@vger.kernel.org
Cc: Leo Yan <leo.yan@linaro.org>
Subject: [PATCH v1 3/3] arch_topology: Scale CPU capacity if without CPU raw capacity
Date: Sun, 13 Mar 2022 13:55:12 +0800	[thread overview]
Message-ID: <20220313055512.248571-4-leo.yan@linaro.org> (raw)
In-Reply-To: <20220313055512.248571-1-leo.yan@linaro.org>

Unlike a typical Arm big.LITTLE architecture, some Arm systems (like
Qualcomm SoC msm8996 and msm8939) have two clusters, all CPUs in two
clusters have the same micro architecture, but some CPUs are "fast" and
other are "slow".  On this kind platform, all CPUs have the same raw CPU
capacity but "fast" CPUs have higher maximum frequency than "slow" ones.

Let's see an example, there have two clusters and every cluster have 4
CPUs, every CPU has the same raw CPU capacity.  The cluster 0 has the
maximum frequency 1497.6MHz and the cluster 1 has the maximum frequency
1113.6MHz, if don't specify "capacity-dmips-mhz" in DT, the we will
get below result:

  # cat /sys/devices/system/cpu/cpu*/cpu_capacity
  1024
  1024
  1024
  1024
  1024
  1024
  1024
  1024

If "capacity-dmips-mhz" property is not specified for CPU nodes, the
kernel will fallback to default capacity value SCHED_CAPACITY_SCALE
(1024).  Though CPUs in different clusters have different maximum
frequencies, kernel skips to scale CPU capacity so that every CPU
capacity is always SCHED_CAPACITY_SCALE (1024).

This patch is to scale CPU capacity even though "capacity-dmips-mhz"
property is not specified in DT.  If "capacity-dmips-mhz" property is
absent in DT binding, the array "raw_capacity" is not allocated so we
rollback to use SCHED_CAPACITY_SCALE as raw CPU capacity and proceed
to scale CPU capacity based on maximum frequency.

After apply this patch, we can get below result for up elaborated
platform:

  # cat /sys/devices/system/cpu/cpu*/cpu_capacity
  1024
  1024
  1024
  1024
  761
  761
  761
  761

Signed-off-by: Leo Yan <leo.yan@linaro.org>
---
 drivers/base/arch_topology.c | 15 ++++++++++-----
 1 file changed, 10 insertions(+), 5 deletions(-)

diff --git a/drivers/base/arch_topology.c b/drivers/base/arch_topology.c
index 0687576e880b..ef1fa2e417ea 100644
--- a/drivers/base/arch_topology.c
+++ b/drivers/base/arch_topology.c
@@ -267,20 +267,25 @@ void topology_normalize_cpu_scale(void)
 {
 	u64 capacity;
 	u64 capacity_scale;
+	u32 raw_cpu_capacity;
 	int cpu;
 
-	if (!raw_capacity)
+	if (cap_parsing_failed)
 		return;
 
 	capacity_scale = 1;
 	for_each_possible_cpu(cpu) {
-		capacity = raw_capacity[cpu] * per_cpu(freq_factor, cpu);
+		raw_cpu_capacity =
+			raw_capacity ? raw_capacity[cpu] : SCHED_CAPACITY_SCALE;
+		capacity = raw_cpu_capacity * per_cpu(freq_factor, cpu);
 		capacity_scale = max(capacity, capacity_scale);
 	}
 
 	pr_debug("cpu_capacity: capacity_scale=%llu\n", capacity_scale);
 	for_each_possible_cpu(cpu) {
-		capacity = raw_capacity[cpu] * per_cpu(freq_factor, cpu);
+		raw_cpu_capacity =
+			raw_capacity ? raw_capacity[cpu] : SCHED_CAPACITY_SCALE;
+		capacity = raw_cpu_capacity * per_cpu(freq_factor, cpu);
 		capacity = div64_u64(capacity << SCHED_CAPACITY_SHIFT,
 			capacity_scale);
 		topology_set_cpu_scale(cpu, capacity);
@@ -373,7 +378,7 @@ init_cpu_capacity_callback(struct notifier_block *nb,
 	struct cpufreq_policy *policy = data;
 	int cpu;
 
-	if (!raw_capacity)
+	if (cap_parsing_failed)
 		return 0;
 
 	if (val != CPUFREQ_CREATE_POLICY)
@@ -412,7 +417,7 @@ static int __init register_cpufreq_notifier(void)
 	 * until we have the necessary code to parse the cpu capacity, so
 	 * skip registering cpufreq notifier.
 	 */
-	if (!acpi_disabled || !raw_capacity)
+	if (!acpi_disabled || cap_parsing_failed)
 		return -EINVAL;
 
 	if (!alloc_cpumask_var(&cpus_to_visit, GFP_KERNEL))
-- 
2.25.1


  parent reply	other threads:[~2022-03-13  5:55 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-13  5:55 [PATCH v1 0/3] arch_topology: Correct CPU capacity scaling Leo Yan
2022-03-13  5:55 ` [PATCH v1 1/3] arch_topology: Correct semantics for 'cap_parsing_failed' Leo Yan
2022-03-13  5:55 ` [PATCH v1 2/3] arch_topology: Handle inconsistent binding of CPU raw capacity Leo Yan
2022-03-13  5:55 ` Leo Yan [this message]
2022-03-14 18:10 ` [PATCH v1 0/3] arch_topology: Correct CPU capacity scaling Ionela Voinescu
2022-03-15  3:29   ` Leo Yan
2022-03-15 10:08     ` Sudeep Holla
2022-03-15 14:59       ` Leo Yan
2022-03-15  9:49   ` Sudeep Holla

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=20220313055512.248571-4-leo.yan@linaro.org \
    --to=leo.yan@linaro.org \
    --cc=bryan.odonoghue@linaro.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rafael@kernel.org \
    --cc=sudeep.holla@arm.com \
    --cc=vincent.guittot@linaro.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 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).