From: Ionela Voinescu <ionela.voinescu@arm.com> To: mingo@redhat.com, peterz@infradead.org, vincent.guittot@linaro.org, catalin.marinas@arm.com, will@kernel.org, rjw@rjwysocki.net, viresh.kumar@linaro.org Cc: dietmar.eggemann@arm.com, qperret@google.com, valentin.schneider@arm.com, linux-pm@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, ionela.voinescu@arm.com Subject: [PATCH RESEND v2 3/3] sched/topology: condition EAS enablement on FIE support Date: Tue, 27 Oct 2020 18:07:13 +0000 [thread overview] Message-ID: <20201027180713.7642-4-ionela.voinescu@arm.com> (raw) In-Reply-To: <20201027180713.7642-1-ionela.voinescu@arm.com> 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. Signed-off-by: Ionela Voinescu <ionela.voinescu@arm.com> Suggested-by: Quentin Perret <qperret@google.com> Cc: Ingo Molnar <mingo@redhat.com> Cc: Peter Zijlstra <peterz@infradead.org> --- kernel/sched/topology.c | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/kernel/sched/topology.c b/kernel/sched/topology.c index 270bafb73506..5a1580ef1264 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)) -- 2.17.1
WARNING: multiple messages have this Message-ID (diff)
From: Ionela Voinescu <ionela.voinescu@arm.com> To: mingo@redhat.com, peterz@infradead.org, vincent.guittot@linaro.org, catalin.marinas@arm.com, will@kernel.org, rjw@rjwysocki.net, viresh.kumar@linaro.org Cc: linux-pm@vger.kernel.org, qperret@google.com, linux-kernel@vger.kernel.org, dietmar.eggemann@arm.com, ionela.voinescu@arm.com, valentin.schneider@arm.com, linux-arm-kernel@lists.infradead.org Subject: [PATCH RESEND v2 3/3] sched/topology: condition EAS enablement on FIE support Date: Tue, 27 Oct 2020 18:07:13 +0000 [thread overview] Message-ID: <20201027180713.7642-4-ionela.voinescu@arm.com> (raw) In-Reply-To: <20201027180713.7642-1-ionela.voinescu@arm.com> 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. Signed-off-by: Ionela Voinescu <ionela.voinescu@arm.com> Suggested-by: Quentin Perret <qperret@google.com> Cc: Ingo Molnar <mingo@redhat.com> Cc: Peter Zijlstra <peterz@infradead.org> --- kernel/sched/topology.c | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/kernel/sched/topology.c b/kernel/sched/topology.c index 270bafb73506..5a1580ef1264 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)) -- 2.17.1 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2020-10-27 18:07 UTC|newest] Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-10-27 18:07 [PATCH RESEND v2 0/3] condition EAS enablement on FI support Ionela Voinescu 2020-10-27 18:07 ` Ionela Voinescu 2020-10-27 18:07 ` [PATCH RESEND v2 1/3] sched/topology,schedutil: wrap sched domains rebuild Ionela Voinescu 2020-10-27 18:07 ` [PATCH RESEND v2 1/3] sched/topology, schedutil: " Ionela Voinescu 2020-10-30 15:26 ` [PATCH RESEND v2 1/3] sched/topology,schedutil: " Rafael J. Wysocki 2020-10-30 15:26 ` Rafael J. Wysocki 2020-11-05 14:03 ` Ionela Voinescu 2020-11-05 14:03 ` Ionela Voinescu 2020-11-20 12:34 ` [tip: sched/core] sched/topology,schedutil: Wrap " tip-bot2 for Ionela Voinescu 2020-10-27 18:07 ` [PATCH RESEND v2 2/3] arm64: rebuild sched domains on invariance status changes Ionela Voinescu 2020-10-27 18:07 ` Ionela Voinescu 2020-11-10 17:20 ` Catalin Marinas 2020-11-10 17:20 ` Catalin Marinas 2020-11-20 12:34 ` [tip: sched/core] arm64: Rebuild " tip-bot2 for Ionela Voinescu 2020-10-27 18:07 ` Ionela Voinescu [this message] 2020-10-27 18:07 ` [PATCH RESEND v2 3/3] sched/topology: condition EAS enablement on FIE support Ionela Voinescu 2020-11-20 12:34 ` [tip: sched/core] sched/topology: Condition " tip-bot2 for Ionela Voinescu 2020-11-18 11:42 ` [PATCH RESEND v2 0/3] condition EAS enablement on FI support Ionela Voinescu 2020-11-18 11:42 ` Ionela Voinescu 2020-11-18 14:01 ` Peter Zijlstra 2020-11-18 14:01 ` Peter Zijlstra
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=20201027180713.7642-4-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=mingo@redhat.com \ --cc=peterz@infradead.org \ --cc=qperret@google.com \ --cc=rjw@rjwysocki.net \ --cc=valentin.schneider@arm.com \ --cc=vincent.guittot@linaro.org \ --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: linkBe 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.