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

[Rafael J. Wysocki (Intel)]

On Tue, Nov 10, 2026 at 3:56 PM Zhongqiu Han
<zhongqiu.han@xxxxxxxxxxxxxxxx> 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@xxxxxxx> 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@xxxxxxx>
> >>>> 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.

Good point.