From: Ionela Voinescu <ionela.voinescu@arm.com>
To: rjw@rjwysocki.net, viresh.kumar@linaro.org,
catalin.marinas@arm.com, sudeep.holla@arm.com, will@kernel.org,
linux@armlinux.org.uk, valentin.schneider@arm.com
Cc: mingo@redhat.com, peterz@infradead.org, dietmar.eggemann@arm.com,
ionela.voinescu@arm.com, linux-pm@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
Subject: [PATCH 7/8] arch_topology,arm64: define arch_scale_freq_invariant()
Date: Wed, 1 Jul 2020 10:07:50 +0100 [thread overview]
Message-ID: <20200701090751.7543-8-ionela.voinescu@arm.com> (raw)
In-Reply-To: <20200701090751.7543-1-ionela.voinescu@arm.com>
From: Valentin Schneider <valentin.schneider@arm.com>
arch_scale_freq_invariant() is used by schedutil to determine whether
the scheduler's load-tracking signals are frequency invariant. Its
definition is overridable, though by default it is hardcoded to 'true'
if arch_scale_freq_capacity() is defined ('false' otherwise).
This behaviour is not overridden on arm, arm64 and other users of the
generic arch topology driver, which is somewhat precarious:
arch_scale_freq_capacity() will always be defined, yet not all cpufreq
drivers are guaranteed to drive the frequency invariance scale factor
setting. In other words, the load-tracking signals may very well *not*
be frequency invariant.
Now that cpufreq can be queried on whether the current driver is driving
the Frequency Invariance (FI) scale setting, the current situation can
be improved. This combines the query of whether cpufreq supports the
setting of the frequency scale factor, with whether all online CPUs are
counter-based FI enabled.
While cpufreq FI enablement applies at system level, for all CPUs,
counter-based FI support could also be used for only a subset of CPUs to
set the invariance scale factor. Therefore, if cpufreq-based FI support
is present, we consider the system to be invariant. If missing, we
require all online CPUs to be counter-based FI enabled in order for the
full system to be considered invariant.
If the system ends up not being invariant, a new condition is needed in
the counter initialization code that disables all scale factor setting
based on counters.
Precedence of counters over cpufreq use is not important here. The
invariant status is only given to the system if all CPUs have at least
one method of setting the frequency scale factor.
Signed-off-by: Valentin Schneider <valentin.schneider@arm.com>
Signed-off-by: Ionela Voinescu <ionela.voinescu@arm.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will@kernel.org>
Cc: Sudeep Holla <sudeep.holla@arm.com>
---
arch/arm64/kernel/topology.c | 7 +++++++
drivers/base/arch_topology.c | 6 ++++++
include/linux/arch_topology.h | 4 ++++
3 files changed, 17 insertions(+)
diff --git a/arch/arm64/kernel/topology.c b/arch/arm64/kernel/topology.c
index 9a9f2b8dedf5..4064d39bb66d 100644
--- a/arch/arm64/kernel/topology.c
+++ b/arch/arm64/kernel/topology.c
@@ -246,6 +246,13 @@ static int __init init_amu_fie(void)
static_branch_enable(&amu_fie_key);
}
+ /*
+ * If the system is not fully invariant after AMU init, disable
+ * partial use of counters for frequency invariance.
+ */
+ if (!topology_scale_freq_invariant())
+ static_branch_disable(&amu_fie_key);
+
free_valid_mask:
free_cpumask_var(valid_cpus);
diff --git a/drivers/base/arch_topology.c b/drivers/base/arch_topology.c
index 8447e1f30340..8686771b866d 100644
--- a/drivers/base/arch_topology.c
+++ b/drivers/base/arch_topology.c
@@ -21,6 +21,12 @@
#include <linux/sched.h>
#include <linux/smp.h>
+bool topology_scale_freq_invariant(void)
+{
+ return cpufreq_sets_freq_scale() ||
+ arch_freq_counters_available(cpu_online_mask);
+}
+
__weak bool arch_freq_counters_available(const struct cpumask *cpus)
{
return false;
diff --git a/include/linux/arch_topology.h b/include/linux/arch_topology.h
index 4be0315700cb..6272fbc05cde 100644
--- a/include/linux/arch_topology.h
+++ b/include/linux/arch_topology.h
@@ -53,6 +53,10 @@ struct cpu_topology {
};
#ifdef CONFIG_GENERIC_ARCH_TOPOLOGY
+
+extern bool topology_scale_freq_invariant(void);
+#define arch_scale_freq_invariant() topology_scale_freq_invariant()
+
extern struct cpu_topology cpu_topology[NR_CPUS];
#define topology_physical_package_id(cpu) (cpu_topology[cpu].package_id)
--
2.17.1
next prev parent reply other threads:[~2020-07-01 9:10 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-07-01 9:07 [PATCH 0/8] cpufreq: improve frequency invariance support Ionela Voinescu
2020-07-01 9:07 ` [PATCH 1/8] cpufreq: allow drivers to flag custom support for freq invariance Ionela Voinescu
2020-07-01 10:46 ` Viresh Kumar
2020-07-01 13:33 ` Ionela Voinescu
2020-07-01 16:05 ` Rafael J. Wysocki
2020-07-01 18:06 ` Ionela Voinescu
2020-07-02 2:58 ` Viresh Kumar
2020-07-02 11:44 ` Ionela Voinescu
2020-07-06 12:14 ` Dietmar Eggemann
2020-07-09 8:53 ` Ionela Voinescu
2020-07-09 9:09 ` Viresh Kumar
2020-07-01 9:07 ` [PATCH 2/8] cpufreq: move invariance setter calls in cpufreq core Ionela Voinescu
2020-07-01 10:46 ` Viresh Kumar
2020-07-01 15:27 ` Ionela Voinescu
2020-07-01 15:51 ` Rafael J. Wysocki
2020-07-02 3:01 ` Viresh Kumar
2020-07-02 11:45 ` Ionela Voinescu
2020-07-01 9:07 ` [PATCH 3/8] cpufreq,drivers: remove setting of frequency scale factor Ionela Voinescu
2020-07-01 9:07 ` [PATCH 4/8] cpufreq,vexpress-spc: fix Frequency Invariance (FI) for bL switching Ionela Voinescu
2020-07-01 10:46 ` Viresh Kumar
2020-07-01 14:07 ` Ionela Voinescu
2020-07-02 3:05 ` Viresh Kumar
2020-07-02 11:41 ` Ionela Voinescu
2020-07-02 11:46 ` Viresh Kumar
2020-07-01 9:07 ` [PATCH 5/8] cpufreq: report whether cpufreq supports Frequency Invariance (FI) Ionela Voinescu
2020-07-01 10:46 ` Viresh Kumar
2020-07-01 9:07 ` [PATCH 6/8] arch_topology,cpufreq,sched/core: constify arch_* cpumasks Ionela Voinescu
2020-07-01 9:07 ` Ionela Voinescu [this message]
2020-07-01 9:07 ` [PATCH 8/8] cpufreq: make schedutil the default for arm and arm64 Ionela Voinescu
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=20200701090751.7543-8-ionela.voinescu@arm.com \
--to=ionela.voinescu@arm.com \
--cc=catalin.marinas@arm.com \
--cc=dietmar.eggemann@arm.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=linux@armlinux.org.uk \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=rjw@rjwysocki.net \
--cc=sudeep.holla@arm.com \
--cc=valentin.schneider@arm.com \
--cc=viresh.kumar@linaro.org \
--cc=will@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®