Re: [PATCH v2] PM: EM: Exclude boost frequencies from inefficiency ranking

[Guo Chen <guo.chen@oss.qualcomm.com>]

On 11/10/2026 10:59 PM, Rafael J. Wysocki (Intel) wrote:
> On Tue, Nov 10, 2026 at 3:56 PM Zhongqiu Han
> <zhongqiu.han@oss.qualcomm.com> wrote:
>> On 11/10/2026 10:05 PM, Lukasz Luba wrote:
>>>
>>> On 11/10/26 13:43, Rafael J. Wysocki (Intel) wrote:
>>>> On Tue, Nov 10, 2026 at 2:11 PM Lukasz Luba <lukasz.luba@arm.com> wrote:
>>>>> Hi Rafael,
>>>>>
>>>>> On 11/10/26 12:15, Rafael J. Wysocki (Intel) wrote:
>>>>>> On Tue, Nov 10, 2026 at 10:58 AM Lukasz Luba <lukasz.luba@arm.com>
>>>>>> wrote:
>>>>> [snip]
>>>>>
>>>>>
>>>>>>> That's fine, please continue.
>>>>>> I have a couple of questions though.
>>>>>>
>>>>>> First, why is the ondemand governor mentioned in the changelog?  In
>>>>>> the mainline, the ondemand governor cannot work with EAS, so it
>>>>>> shouldn't matter for this issue, should it?
>>>>> The ondemand is affected by the EM setup code and set 'inefficient'
>>>>> flags for some OPPs. The EM is also present for cooling devices
>>>>> and can work w/o EAS and schedutil, w/ just ondemand governor.
>>>>>
>>>>> Because EM marks the OPPs kind of 'globally' as inefficient, then
>>>>> they become CPUFREQ_INEFFICIENT_FREQ entries in the CPUfreq fwk.
>>>>> In the EM code we have:
>>>>> cpufreq_table_set_inefficient(policy, table[i].frequency);
>>>> So maybe this is the one that needs to be fixed?  What about simply
>>>> skipping boost frequencies in it?
>>>>
>>>>> Then ondemand check for CPUFREQ_RELATION_HE will skip them and
>>>>> pass to __cpufreq_driver_target() with that flags as well.
>>>> Thanks for explaining and all of that needs to be said in the patch
>>>> changelog.
>>>>
>>>>>> Second, why is the issue regarded as a defect in the code and not in
>>>>>> the energy model?  Arguably, boost frequencies should be more costly
>>>>>> than the non-boost ones.  At least the idea behind the boost is making
>>>>>> higher-cost OPPs temporarily available.  If they are sustainable,
>>>>>> treating them as boost OPPs is rather pointless.
>>>>> IMHO it was a bug in the commit mentioned in this patch fix tag.
>>>>> It is affecting more than just EAS or EM, since the EM is working with
>>>>> all generic code and all cpufreq governors.
>>>> To be precise, the EM initialization may affect cpufreq in general
>>>> because inefficient frequencies are used for CPU cooling.  Fair
>>>> enough, but I'm not talking about this.
>>>>
>>>> I'm talking about a reason for giving boost frequencies lower or equal
>>>> cost relative to non-boost frequencies in the energy model because
>>>> this doesn't make sense to me TBH.
>>>>
>>>> And I get that such energy models were there before the commit in
>>>> question and now they are not working properly, but IMO they are
>>>> broken, not that commit.
>>>>
>>>>>> TBH, I'm too comfortable with looking at cpufreq frequency from within
>>>>>> the EM code.  If that needs to be done, something is amiss at the
>>>>>> design level.
>>>>> I think this edge case is special, as I described above.
>>>>>
>>>>> I'm happy to hear your view on this EM influence to some global
>>>>> setting in cpufreq. Maybe it was too far to establish this
>>>>> 'inefficiency' flags in there for many usage?
>>>> There's nothing wrong with using the information from the energy
>>>> model, when available, to amend cpufreq, but the patch goes the other
>>>> way around: It tries to amend the energy model with information taken
>>>> from cpufreq (in order to avoid making mistakes later when amending
>>>> cpufreq with the energy model information).
>>>>
>>>> I think that cpufreq should simply refuse to set
>>>> CPUFREQ_INEFFICIENT_FREQ for boost frequencies.  Wouldn't that work?


Got your point. Having cpufreq directly refuse to set
CPUFREQ_INEFFICIENT_FREQ might be the simplest approach. Let me
summarize my understanding. There are two cases where we can
simply avoid setting the CPUFREQ_INEFFICIENT_FREQ flag:
1. boost frequencies.
2. the highest non-boost frequency.

However, there is another issue. If we refuse to set
CPUFREQ_INEFFICIENT_FREQ for certain frequencies, I think the
corresponding EM_PERF_STATE_INEFFICIENT flags in the Energy Model
also need to be updated. Otherwise, the EM state would be inconsistent
with the frequencies used for energy estimation in the EAS path.

I think we also need to update the EM_PERF_STATE_INEFFICIENT flags
accordingly, something like the following:

for (i = 0; i < pd->nr_perf_states; i++) {
     int ret;

     if (!(table[i].flags & EM_PERF_STATE_INEFFICIENT))
         continue;

     /*Return -EOPNOTSUPP if the rejection condition is met. */
     ret = cpufreq_table_set_inefficient(policy, table[i].frequency);
     if (!ret)
         found++;
     else if (ret == -EOPNOTSUPP)
         table[i].flags &= ~EM_PERF_STATE_INEFFICIENT;
}

>>> I see your point now, about the direction. Yes, you're right.
>>>
>>> Since we are taking the information about 'boost' from the
>>> cpufreq, then refusing to set OPPs inefficient in the first
>>> place makes more sense.
>>>
>>>
>> I also agree this should be fixed in cpufreq rather than by feeding
>> cpufreq information into the EM. However, refusing
>> CPUFREQ_INEFFICIENT_FREQ for boost frequencies seems not help the
>> example in the changelog, because the frequency marked as inefficient
>> there is 4.0 GHz, which is not a boost one. The problem is not specific
>> to boost either: with 3.9 GHz, 4.0 GHz, 4.1 GHz and a 4.2 GHz boost OPP
>> at costs C - d, C, C and C + d, 4.0 GHz is rightly inefficient, but if
>> policy->max is capped at 4.0 GHz by scaling_max_freq, thermal or QoS,
>> RELATION_HE for 4.0 GHz still resolves to 3.9 GHz. I think the lookup
>> should not skip an inefficient frequency when the next efficient
>> frequency above it is beyond the max limit, which can be done in
>> cpufreq_frequency_table_target() without touching the EM or looking at
>> boost flags.


@Zhongqiu: thanks for the example. I think the two cases are different in
nature.

In the case of the changelog, the highest non-boost frequency of cluster is
marked inefficient because of the boost frequency. A sustainable 
frequency is
being affected by an unsustainable one, but it is not really inefficient: I
don't think these two kinds of frequencies should be compared with each 
other
in terms of energy. So I think this should be fixed at the source, by not
marking such frequencies as inefficient.

The case you describe looks different, as it is dynamic: policy->max is
changed at runtime by scaling_max_freq, thermal or QoS, which would mean
ignoring the inefficient flag every time policy->max lands on an inefficient
frequency. Whether this is really necessary seems to me to deserve a
discussion. Thermal and QoS limits are there to keep the frequency from 
going
above the cap. In your example (3.9 GHz, 4.0 GHz, 4.1 GHz), if the 
frequency is
limited to 4.0 GHz at some point and ends up on 3.9 GHz because 4.0 GHz is
inefficient, the original purpose of the limit, not going above the cap, is
still honoured.

So I am not sure that handling the dynamic case is needed, and I would 
like to
hear what you, Rafael and Lukasz think about it.

Thanks,
Guo

> Good point.