Re: [PATCH v1] cpufreq: intel_pstate: Adjust policy->cur in active mode to policy

[Rafael J. Wysocki (Intel)]

On Thu, Jul 30, 2026 at 5:01 PM Doug Smythies <dsmythies@xxxxxxxxx> wrote:
>
> On 2026.07.29 16:30 Doug Smythies wrote:
> > On 2026.07.29 11:40 Rafael wrote:
> >> On Wednesday, July 29, 2026 10:59:24 AM CEST Jing Wu wrote:
>
> ...
>
> >>> arch_freq_get_on_cpu() falls back to cpufreq_quick_get(), i.e.
> >>> policy->cur, whenever its APERF/MPERF sample goes stale. A CPU whose
> >>> tick keeps running refreshes that sample constantly and rarely hits
> >>> the fallback, but an isolated CPU covered by nohz_full with a single
> >>> runnable task never gets another tick, so it permanently reports the
> >>> floor through this fallback - even though it is genuinely pinned to,
> >>> and running at, the frequency computed just above.
>
> I was unable to recreate your described situation.
> With some isolated CPUs and a single runnable task, the reported
> frequency was always accurate, and when there was no task the stale
> frequency was as expected.
>
> ...
>
> >> Good idea overall, but it takes a bit more to do this.  In particular, the HWP
> >> case needs some more care.
> >>
> >> Also, I don't think that this really is a fix.  The code works as intended,
> >> although what it does is sometimes confusing.
> >
> > Yes, and by agreement at the time (or so I think I recall) we
> > were trying to get all CPU frequency scaling drivers and governors to
> > display the same thing when the frequency was stale.
> > We wanted to: 1, make it more obvious that the frequency was stale;
> > 2, keep the listed stale frequency within the currently set limits.
> > The drivers were intel_pstate (with both HWP enabled and disabled),
> > intel_cpufreq (with both HWP enabled and disabled), and acpi-cpufreq.
> > We decided on the currently set minimum CPU frequency.
> >
> > There was a problem with driver = intel_cpufreq, governor = schedutil,
> > HWP enabled, where it would might not show the current minimum
> > frequency as the stale frequency, that remains to this day.
> > (i.e. I have never figured out a fix after my initial attempt was rejected, [1])
> >
> >> Below is my version of this change (on top of linux-next), please let me know
> >> if it works for you.
> >>
> >> Thanks!
> >
> > I was part way through looking at and testing Jing's version of the patch.
> > I'll abandon that and try yours.
>
> Thanks, your patch also eliminates a lingering difference in reported stale
> frequencies with the performance governor between the intel_pstate and
> intel_cpufreq CPU frequency scaling drivers.
>
> A table of all combinations is attached.
>
> Reviewed and tested by dsmythies@xxxxxxxxx

Thank you!