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

[Lukasz Luba <lukasz.luba@arm.com>]

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);


Then ondemand check for CPUFREQ_RELATION_HE will skip them and
pass to __cpufreq_driver_target() with that flags as well.


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


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

Regards,
Lukasz