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
| ||
|
Date: Fri, 20 Nov 2020 12:34:04 -0000 From: "tip-bot2 for Ionela Voinescu" <tip-bot2@...utronix.de> To: linux-tip-commits@...r.kernel.org Cc: Quentin Perret <qperret@...gle.com>, Ionela Voinescu <ionela.voinescu@....com>, "Peter Zijlstra (Intel)" <peterz@...radead.org>, x86@...nel.org, linux-kernel@...r.kernel.org Subject: [tip: sched/core] sched/topology: Condition EAS enablement on FIE support The following commit has been merged into the sched/core branch of tip: Commit-ID: fa50e2b452c60cff9f4000de5b372a61d6695c26 Gitweb: https://git.kernel.org/tip/fa50e2b452c60cff9f4000de5b372a61d6695c26 Author: Ionela Voinescu <ionela.voinescu@....com> AuthorDate: Tue, 27 Oct 2020 18:07:13 Committer: Peter Zijlstra <peterz@...radead.org> CommitterDate: Thu, 19 Nov 2020 11:25:47 +01:00 sched/topology: Condition EAS enablement on FIE support In order to make accurate predictions across CPUs and for all performance states, Energy Aware Scheduling (EAS) needs frequency-invariant load tracking signals. EAS task placement aims to minimize energy consumption, and does so in part by limiting the search space to only CPUs with the highest spare capacity (CPU capacity - CPU utilization) in their performance domain. Those candidates are the placement choices that will keep frequency at its lowest possible and therefore save the most energy. But without frequency invariance, a CPU's utilization is relative to the CPU's current performance level, and not relative to its maximum performance level, which determines its capacity. As a result, it will fail to correctly indicate any potential spare capacity obtained by an increase in a CPU's performance level. Therefore, a non-invariant utilization signal would render the EAS task placement logic invalid. Now that we properly report support for the Frequency Invariance Engine (FIE) through arch_scale_freq_invariant() for arm and arm64 systems, while also ensuring a re-evaluation of the EAS use conditions for possible invariance status change, we can assert this is the case when initializing EAS. Warn and bail out otherwise. Suggested-by: Quentin Perret <qperret@...gle.com> Signed-off-by: Ionela Voinescu <ionela.voinescu@....com> Signed-off-by: Peter Zijlstra (Intel) <peterz@...radead.org> Link: https://lkml.kernel.org/r/20201027180713.7642-4-ionela.voinescu@arm.com --- kernel/sched/topology.c | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/kernel/sched/topology.c b/kernel/sched/topology.c index 04d9ebf..5d3675c 100644 --- a/kernel/sched/topology.c +++ b/kernel/sched/topology.c @@ -328,6 +328,7 @@ static void sched_energy_set(bool has_eas) * 3. no SMT is detected. * 4. the EM complexity is low enough to keep scheduling overheads low; * 5. schedutil is driving the frequency of all CPUs of the rd; + * 6. frequency invariance support is present; * * The complexity of the Energy Model is defined as: * @@ -376,6 +377,14 @@ static bool build_perf_domains(const struct cpumask *cpu_map) goto free; } + if (!arch_scale_freq_invariant()) { + if (sched_debug()) { + pr_warn("rd %*pbl: Disabling EAS: frequency-invariant load tracking not yet supported", + cpumask_pr_args(cpu_map)); + } + goto free; + } + for_each_cpu(i, cpu_map) { /* Skip already covered CPUs. */ if (find_pd(pd, i))
Powered by blists - more mailing lists