Re: [PATCH v2] PM: EM: Exclude boost frequencies from inefficiency ranking
From: Lukasz Luba
Date: Mon Nov 09 2026 - 04:51:12 EST
On 11/9/26 06:47, Guo Chen wrote:
I also thought about that possible racy corner case, where
On 11/6/2026 11:15 PM, Rafael J. Wysocki (Intel) wrote:
On Tue, Nov 3, 2026 at 12:21 PM Guo Chen <guo.chen@xxxxxxxxxxxxxxxx> wrote:em_compute_costs() ranks all the frequencies of the table, boost onesPlease see Sashiko's feedback regarding this patch
included. A non-boost frequency can be marked inefficient only because
a faster boost frequency has a lower or equal cost, e.g.
3.9 GHz 4.0 GHz (cost C) 4.1 GHz (boost, cost C)
With boost disabled 4.1 GHz cannot be selected, but 4.0 GHz is still
skipped by governors rounding down to efficient frequencies (e.g.
ondemand with CPUFREQ_RELATION_HE), which land on 3.9 GHz instead of
the best selectable frequency. Several frequencies can be affected.
Exclude the boost frequencies from the ranking in em_compute_costs() and
keep them all efficient, using the highest non-boost frequency of the
CPUFreq table, returned by the new helper
cpufreq_table_max_nonboost_freq(), as the boundary.
Fixes: c8ed99533dbc ("PM: EM: Mark inefficient states")
Signed-off-by: Guo Chen <guo.chen@xxxxxxxxxxxxxxxx>
https://sashiko.dev/#/patchset/20261103-em-rank-boost-separately- v2-1-5a13d1b38d37%40oss.qualcomm.com
and tell me what you think about it.
Thanks!
Thanks for the review.
I did consider this case. If no policy is found, max_nonboost stays 0 and
the new logic is bypassed, i.e. the ranking falls back to the old
behaviour, which looked like the least intrusive option. I also thought
about warning and returning an error, but most of the in-tree callers of
em_recalc_and_update() ignore the return value (e.g.
em_adjust_new_capacity() and exynos_asv_update_opps()), so the update would
just be dropped without anyone noticing.
---
Changes in v2:
- Drop prev_boost and keep all boost states efficient by resetting
prev_cost for them, as suggested by Lukasz. Boost states are no
longer ranked against each other.
- Retitle the patch to match the new behaviour (was "Rank boost and
non-boost frequencies separately") and reword the commit message.
Link to v1: https://lore.kernel.org/all/20261030-em-rank-boost- separately-v1-1-238a6b2bb888@xxxxxxxxxxxxxxxx/
---
include/linux/cpufreq.h | 24 ++++++++++++++++++++++++
kernel/power/energy_model.c | 16 ++++++++++++++++
2 files changed, 40 insertions(+)
diff --git a/include/linux/cpufreq.h b/include/linux/cpufreq.h
index d3d0d9d02aa4..c93316141a11 100644
--- a/include/linux/cpufreq.h
+++ b/include/linux/cpufreq.h
@@ -1155,6 +1155,24 @@ cpufreq_table_set_inefficient(struct cpufreq_policy *policy,
return -EINVAL;
}
+static inline unsigned int
+cpufreq_table_max_nonboost_freq(struct cpufreq_policy *policy)
+{
+ struct cpufreq_frequency_table *pos;
+ unsigned int max = 0;
+
+ if (!policy->freq_table)
+ return 0;
+
+ /* The table may be unsorted, scan all of it for the highest one. */
+ cpufreq_for_each_valid_entry(pos, policy->freq_table) {
+ if (!(pos->flags & CPUFREQ_BOOST_FREQ) && pos- >frequency > max)
+ max = pos->frequency;
+ }
+
+ return max;
+}
+
static inline int parse_perf_domain(int cpu, const char *list_name,
const char *cell_name,
struct of_phandle_args *args)
@@ -1219,6 +1237,12 @@ cpufreq_table_set_inefficient(struct cpufreq_policy *policy,
return -EINVAL;
}
+static inline unsigned int
+cpufreq_table_max_nonboost_freq(struct cpufreq_policy *policy)
+{
+ return 0;
+}
+
static inline int of_perf_domain_get_sharing_cpumask(int pcpu, const char *list_name,
const char *cell_name, struct cpumask *cpumask,
struct of_phandle_args *pargs)
diff --git a/kernel/power/energy_model.c b/kernel/power/energy_model.c
index d19a65461ae8..5b1d095fd376 100644
--- a/kernel/power/energy_model.c
+++ b/kernel/power/energy_model.c
@@ -255,15 +255,24 @@ static int em_compute_costs(struct device *dev, struct em_perf_state *table,
unsigned long flags)
{
unsigned long prev_cost = ULONG_MAX;
+ struct cpufreq_policy *policy;
+ unsigned int max_nonboost = 0;
int i, ret;
/* This is needed only for CPUs and EAS skip other devices */
if (!_is_cpu_device(dev))
return 0;
+ policy = cpufreq_cpu_get(dev->id);
+ if (policy) {
+ max_nonboost = cpufreq_table_max_nonboost_freq(policy);
+ cpufreq_cpu_put(policy);
+ }
+
The lookup can be made more robust though: on the update paths dev->id may
be offline while other CPUs of the performance domain are online. In v3, if
dev->id has no policy and the performance domain already exists, I will use
an active CPU of the performance domain instead, as
em_cpufreq_update_efficiencies() does, and only warn and fall back to the
old behaviour if that fails as well.
I did not use the performance domain for every lookup because at
registration time dev->em_pd is not assigned yet (it is set after
em_create_perf_table() has returned):
policy = cpufreq_cpu_get(dev->id);
if (!policy && dev->em_pd) {
cpu = cpumask_first_and(em_span_cpus(dev->em_pd), cpu_active_mask);
if (cpu < nr_cpu_ids)
policy = cpufreq_cpu_get(cpu);
}
if (policy) {
max_nonboost = cpufreq_table_max_nonboost_freq(policy);
cpufreq_cpu_put(policy);
} else {
dev_warn(dev, "EM: no CPUFreq policy, boost states are "
"not excluded from the ranking\n");
}
This makes it much less likely to miss the policy, but cannot rule it out:
the CPU can still go offline between picking it and calling
cpufreq_cpu_get(). em_cpufreq_update_efficiencies() has the same
limitation.
Would that work for you?
CPU can go offline (or already be offline). Although, in current
usage this should be OK, since we do this in boot phase and
platforms are sane.
We can can add that step with 'cpu_active_mask' to play safe,
but no hard promises it would be atomic.
The warning also would help, for bring-up phase, so engineers would
notice it and address the racy hot-plug booting system when it's there.