mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Lukasz Luba <lukasz.luba@arm.com>
To: Guo Chen <guo.chen@oss.qualcomm.com>
Cc: Viresh Kumar <viresh.kumar@linaro.org>,
	Pavel Machek <pavel@kernel.org>, Len Brown <lenb@kernel.org>,
	Vincent Donnefort <vincent.donnefort@arm.com>,
	Matthias Kaehlcke <mka@chromium.org>,
	"Rafael J . Wysocki" <rafael.j.wysocki@intel.com>,
	linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org,
	stable@vger.kernel.org, xin.liu@oss.qualcomm.com,
	aiqun.yu@oss.qualcomm.com, tengfei.fan@oss.qualcomm.com,
	tingwei.zhang@oss.qualcomm.com,
	"Rafael J. Wysocki (Intel)" <rafael@kernel.org>
Subject: Re: [PATCH v2] PM: EM: Exclude boost frequencies from inefficiency ranking
Date: Tue, 10 Nov 2026 09:58:58 +0000	[thread overview]
Message-ID: <6b0ee061-38b9-413e-9a83-90446b484859@arm.com> (raw)
In-Reply-To: <901516c9-d1be-4918-840e-e3617f2a1782@oss.qualcomm.com>



On 11/10/26 09:49, Guo Chen wrote:
> 
> On 11/9/2026 5:40 PM, Lukasz Luba wrote:
>>
>>
>> On 11/9/26 06:47, Guo Chen wrote:
>>>
>>> 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@oss.qualcomm.com> 
>>>> wrote:
>>>>> em_compute_costs() ranks all the frequencies of the table, boost ones
>>>>> 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@oss.qualcomm.com>
>>>> Please see Sashiko's feedback regarding this patch
>>>>
>>>> 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@oss.qualcomm.com/
>>>>> ---
>>>>>   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?
>> I also thought about that possible racy corner case, where
>> 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.
> 
> Thanks Lukasz,
> 
> I’ll add the 'cpu_active_mask' check and the warning in v3. As the
> overall approach is unchanged, I’ll keep your reviewed-by.
> Please let me know if you’d rather have it removed.

That's fine, please continue.


  reply	other threads:[~2026-11-10  9:58 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-11-03 11:21 Guo Chen
2026-11-05 13:23 ` Lukasz Luba
2026-11-06 15:15 ` Rafael J. Wysocki (Intel)
2026-11-09  6:47   ` Guo Chen
2026-11-09  9:40     ` Lukasz Luba
2026-11-10  9:49       ` Guo Chen
2026-11-10  9:58         ` Lukasz Luba [this message]
2026-11-10 12:15           ` Rafael J. Wysocki (Intel)
2026-11-10 13:11             ` Lukasz Luba
2026-11-10 13:43               ` Rafael J. Wysocki (Intel)
2026-11-10 14:05                 ` Lukasz Luba
2026-11-10 14:55                   ` Zhongqiu Han
2026-11-10 14:59                     ` Rafael J. Wysocki (Intel)

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=6b0ee061-38b9-413e-9a83-90446b484859@arm.com \
    --to=lukasz.luba@arm.com \
    --cc=aiqun.yu@oss.qualcomm.com \
    --cc=guo.chen@oss.qualcomm.com \
    --cc=lenb@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=mka@chromium.org \
    --cc=pavel@kernel.org \
    --cc=rafael.j.wysocki@intel.com \
    --cc=rafael@kernel.org \
    --cc=stable@vger.kernel.org \
    --cc=tengfei.fan@oss.qualcomm.com \
    --cc=tingwei.zhang@oss.qualcomm.com \
    --cc=vincent.donnefort@arm.com \
    --cc=viresh.kumar@linaro.org \
    --cc=xin.liu@oss.qualcomm.com \
    /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®