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

["Doug Smythies" <dsmythies@telus.net>]

[-- Attachment #1: Type: text/plain, Size: 2575 bytes --]

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@telus.net

>
> ... deleted the rest ...
>
> [1] https://lore.kernel.org/linux-pm/CAAYoRsU2=qOUhBKSRskcoRXSgBudWgDNVvKtJA+c22cPa8EZ1Q@mail.gmail.com/

... Doug


[-- Attachment #2: stale-freq-values-kernel-7-2-rc5.png --]
[-- Type: image/png, Size: 82358 bytes --]