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

[Zhongqiu Han <zhongqiu.han@oss.qualcomm.com>]

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?
> 
> 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.

> 


-- 
Thx and BRs,
Zhongqiu Han