[v1,0/6] intel_pstate: Turbo disabled handling rework

Message

Rafael J. Wysocki March 25, 2024, 5 p.m. UTC

Hi Everyone,

This series reworks the handling of disabling turbo in intel_pstate
on top of the previous series of cleanups

https://lore.kernel.org/linux-pm/12409658.O9o76ZdvQC@kreacher/

The underlying problem is that disabling turbo is handled quite consistently
in intel_pstate and basically it can get disabled at any time (through
MSR_IA32_MISC_ENABLE_TURBO_DISABLE) without much coordination with the
cpufreq core or anything else.

Disabling turbo through the "no_turbo" sysfs attribute is more consistent,
but it has issues too (for example, if turbo is disabled via "no_turbo",
the frequency-invariance code gets notified on the turbo status change,
but the actual maximum frequency of the CPU is only updated if the
MSR_IA32_MISC_ENABLE_TURBO_DISABLE value changes either, which need not
happen at the same time or even at all).

The first patch is not really related to the rest of the series, it's
just a cleanup and can be applied separately.

Patch [2/6] uses the observation that it should be necessary to read
MSR_IA32_MISC_ENABLE_TURBO_DISABLE after driver initialization to remove
in-flight reads on that MSR and turbo state updates related to them.

Patch [3/6] builds on top of the previous one to adjust the "no_turbo"
attribute "store" and "show" callbacks.

Patch [4/6] adds READ_ONCE() annotations to global.no_turbo accesses and
makes some related simplifications.

Patch [5/6] replaces the cached MSR_IA32_MISC_ENABLE_TURBO_DISABLE
value in some checks with global.no_turbo for consistency.

Patch [6/6] makes all of the code paths where the maximum CPU frequency
can change to do that consistently by using the same set of functions.

Details are described in the individual patch changelogs.

Thanks!

Comments

srinivas pandruvada April 2, 2024, 8:46 a.m. UTC | #1

On Mon, 2024-03-25 at 18:00 +0100, Rafael J. Wysocki wrote:
> Hi Everyone,
> 
> This series reworks the handling of disabling turbo in intel_pstate
> on top of the previous series of cleanups
> 
> https://lore.kernel.org/linux-pm/12409658.O9o76ZdvQC@kreacher/
> 
> The underlying problem is that disabling turbo is handled quite
> consistently
> in intel_pstate and basically it can get disabled at any time
> (through
> MSR_IA32_MISC_ENABLE_TURBO_DISABLE) without much coordination with
> the
> cpufreq core or anything else.
> 
> Disabling turbo through the "no_turbo" sysfs attribute is more
> consistent,
> but it has issues too (for example, if turbo is disabled via
> "no_turbo",
> the frequency-invariance code gets notified on the turbo status
> change,
> but the actual maximum frequency of the CPU is only updated if the
> MSR_IA32_MISC_ENABLE_TURBO_DISABLE value changes either, which need
> not
> happen at the same time or even at all).
> 
> The first patch is not really related to the rest of the series, it's
> just a cleanup and can be applied separately.
> 
> Patch [2/6] uses the observation that it should be necessary to read
> MSR_IA32_MISC_ENABLE_TURBO_DISABLE after driver initialization to
> remove
> in-flight reads on that MSR and turbo state updates related to them.
> 
> Patch [3/6] builds on top of the previous one to adjust the
> "no_turbo"
> attribute "store" and "show" callbacks.
> 
> Patch [4/6] adds READ_ONCE() annotations to global.no_turbo accesses
> and
> makes some related simplifications.
> 
> Patch [5/6] replaces the cached MSR_IA32_MISC_ENABLE_TURBO_DISABLE
> value in some checks with global.no_turbo for consistency.
> 
> Patch [6/6] makes all of the code paths where the maximum CPU
> frequency
> can change to do that consistently by using the same set of
> functions.
> 
> Details are described in the individual patch changelogs.
> 

Acked-by: Srinivas Pandruvada <[e-mail]>

Thanks,
Srinivas

> Thanks!
> 
> 
> 
>