Linux Power Management development
 help / color / mirror / Atom feed
* [PATCH v1] cpufreq: Make cpufreq_update_pressure() fall back to cpuinfo.max_freq
@ 2026-07-07 17:25 Rafael J. Wysocki
  2026-07-08  3:44 ` Viresh Kumar
                   ` (2 more replies)
  0 siblings, 3 replies; 5+ messages in thread
From: Rafael J. Wysocki @ 2026-07-07 17:25 UTC (permalink / raw)
  To: Linux PM
  Cc: Vincent Guittot, LKML, Srinivas Pandruvada, Viresh Kumar,
	Dhruva Gole, Lukasz Luba, Qais Yousef, Ingo Molnar

From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

If arch_scale_freq_ref() is not defined for a given arch (like x86, for
example), cpufreq_update_pressure() will always set cpufreq_pressure to
zero for all CPUs in the system, which is generally problematic on
systems with asymmetric capacity [1].

However, in the absence of arch_scale_freq_ref(), it is reasonable
to assume that cpuinfo.max_freq is the maximum sustainable frequency
for the given cpufreq policy.  Moreover, there are cases in which
arch_scale_freq_ref() would need to be defined to return essentially
the cpuinfo.max_freq value anyway (for example, intel_pstate on
hybrid platforms).

For the above reasons, update cpufreq_update_pressure() to fall back to
using cpuinfo.max_freq as the reference frequency if zero is returned by
arch_scale_freq_ref().

Fixes: 75d659317bb1 ("cpufreq: Add a cpufreq pressure feedback for the scheduler")
Link: https://lore.kernel.org/lkml/CAKfTPtBuRLfYNnR4w--cFZYZy-R8gaPEgVwCcaMmbCcJ2H-muQ@mail.gmail.com/ [1]
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
---
 drivers/cpufreq/cpufreq.c |    3 +++
 1 file changed, 3 insertions(+)

--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -2590,6 +2590,9 @@ static void cpufreq_update_pressure(stru
 
 	cpu = cpumask_first(policy->related_cpus);
 	max_freq = arch_scale_freq_ref(cpu);
+	if (!max_freq)
+		max_freq = policy->cpuinfo.max_freq;
+
 	capped_freq = policy->max;
 
 	/*




^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [PATCH v1] cpufreq: Make cpufreq_update_pressure() fall back to cpuinfo.max_freq
  2026-07-07 17:25 [PATCH v1] cpufreq: Make cpufreq_update_pressure() fall back to cpuinfo.max_freq Rafael J. Wysocki
@ 2026-07-08  3:44 ` Viresh Kumar
  2026-07-08  4:09   ` Zhongqiu Han
  2026-07-08 17:13 ` Ricardo Neri
  2026-07-09 13:00 ` Vincent Guittot
  2 siblings, 1 reply; 5+ messages in thread
From: Viresh Kumar @ 2026-07-08  3:44 UTC (permalink / raw)
  To: Rafael J. Wysocki
  Cc: Linux PM, Vincent Guittot, LKML, Srinivas Pandruvada, Dhruva Gole,
	Lukasz Luba, Qais Yousef, Ingo Molnar

On 07-07-26, 19:25, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> 
> If arch_scale_freq_ref() is not defined for a given arch (like x86, for
> example), cpufreq_update_pressure() will always set cpufreq_pressure to
> zero for all CPUs in the system, which is generally problematic on
> systems with asymmetric capacity [1].
> 
> However, in the absence of arch_scale_freq_ref(), it is reasonable
> to assume that cpuinfo.max_freq is the maximum sustainable frequency
> for the given cpufreq policy.  Moreover, there are cases in which
> arch_scale_freq_ref() would need to be defined to return essentially
> the cpuinfo.max_freq value anyway (for example, intel_pstate on
> hybrid platforms).
> 
> For the above reasons, update cpufreq_update_pressure() to fall back to
> using cpuinfo.max_freq as the reference frequency if zero is returned by
> arch_scale_freq_ref().
> 
> Fixes: 75d659317bb1 ("cpufreq: Add a cpufreq pressure feedback for the scheduler")
> Link: https://lore.kernel.org/lkml/CAKfTPtBuRLfYNnR4w--cFZYZy-R8gaPEgVwCcaMmbCcJ2H-muQ@mail.gmail.com/ [1]
> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> ---
>  drivers/cpufreq/cpufreq.c |    3 +++
>  1 file changed, 3 insertions(+)
> 
> --- a/drivers/cpufreq/cpufreq.c
> +++ b/drivers/cpufreq/cpufreq.c
> @@ -2590,6 +2590,9 @@ static void cpufreq_update_pressure(stru
>  
>  	cpu = cpumask_first(policy->related_cpus);
>  	max_freq = arch_scale_freq_ref(cpu);
> +	if (!max_freq)
> +		max_freq = policy->cpuinfo.max_freq;
> +
>  	capped_freq = policy->max;
>  
>  	/*

Acked-by: Viresh Kumar <viresh.kumar@linaro.org>

-- 
viresh

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [PATCH v1] cpufreq: Make cpufreq_update_pressure() fall back to cpuinfo.max_freq
  2026-07-08  3:44 ` Viresh Kumar
@ 2026-07-08  4:09   ` Zhongqiu Han
  0 siblings, 0 replies; 5+ messages in thread
From: Zhongqiu Han @ 2026-07-08  4:09 UTC (permalink / raw)
  To: Viresh Kumar, Rafael J. Wysocki
  Cc: Linux PM, Vincent Guittot, LKML, Srinivas Pandruvada, Dhruva Gole,
	Lukasz Luba, Qais Yousef, Ingo Molnar, zhongqiu.han

On 7/8/2026 11:44 AM, Viresh Kumar wrote:
> On 07-07-26, 19:25, Rafael J. Wysocki wrote:
>> From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
>>
>> If arch_scale_freq_ref() is not defined for a given arch (like x86, for
>> example), cpufreq_update_pressure() will always set cpufreq_pressure to
>> zero for all CPUs in the system, which is generally problematic on
>> systems with asymmetric capacity [1].
>>
>> However, in the absence of arch_scale_freq_ref(), it is reasonable
>> to assume that cpuinfo.max_freq is the maximum sustainable frequency
>> for the given cpufreq policy.  Moreover, there are cases in which
>> arch_scale_freq_ref() would need to be defined to return essentially
>> the cpuinfo.max_freq value anyway (for example, intel_pstate on
>> hybrid platforms).
>>
>> For the above reasons, update cpufreq_update_pressure() to fall back to
>> using cpuinfo.max_freq as the reference frequency if zero is returned by
>> arch_scale_freq_ref().
>>
>> Fixes: 75d659317bb1 ("cpufreq: Add a cpufreq pressure feedback for the scheduler")
>> Link: https://lore.kernel.org/lkml/CAKfTPtBuRLfYNnR4w--cFZYZy-R8gaPEgVwCcaMmbCcJ2H-muQ@mail.gmail.com/ [1]
>> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
>> ---
>>   drivers/cpufreq/cpufreq.c |    3 +++
>>   1 file changed, 3 insertions(+)
>>
>> --- a/drivers/cpufreq/cpufreq.c
>> +++ b/drivers/cpufreq/cpufreq.c
>> @@ -2590,6 +2590,9 @@ static void cpufreq_update_pressure(stru
>>   
>>   	cpu = cpumask_first(policy->related_cpus);
>>   	max_freq = arch_scale_freq_ref(cpu);
>> +	if (!max_freq)
>> +		max_freq = policy->cpuinfo.max_freq;
>> +
>>   	capped_freq = policy->max;
>>   
>>   	/*
> 
> Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
> 

Reviewed-by: Zhongqiu Han <zhongqiu.han@oss.qualcomm.com>

-- 
Thx and BRs,
Zhongqiu Han

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [PATCH v1] cpufreq: Make cpufreq_update_pressure() fall back to cpuinfo.max_freq
  2026-07-07 17:25 [PATCH v1] cpufreq: Make cpufreq_update_pressure() fall back to cpuinfo.max_freq Rafael J. Wysocki
  2026-07-08  3:44 ` Viresh Kumar
@ 2026-07-08 17:13 ` Ricardo Neri
  2026-07-09 13:00 ` Vincent Guittot
  2 siblings, 0 replies; 5+ messages in thread
From: Ricardo Neri @ 2026-07-08 17:13 UTC (permalink / raw)
  To: Rafael J. Wysocki
  Cc: Linux PM, Vincent Guittot, LKML, Srinivas Pandruvada,
	Viresh Kumar, Dhruva Gole, Lukasz Luba, Qais Yousef, Ingo Molnar

On Tue, Jul 07, 2026 at 07:25:39PM +0200, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> 
> If arch_scale_freq_ref() is not defined for a given arch (like x86, for
> example), cpufreq_update_pressure() will always set cpufreq_pressure to
> zero for all CPUs in the system, which is generally problematic on
> systems with asymmetric capacity [1].
> 
> However, in the absence of arch_scale_freq_ref(), it is reasonable
> to assume that cpuinfo.max_freq is the maximum sustainable frequency
> for the given cpufreq policy.  Moreover, there are cases in which
> arch_scale_freq_ref() would need to be defined to return essentially
> the cpuinfo.max_freq value anyway (for example, intel_pstate on
> hybrid platforms).
> 
> For the above reasons, update cpufreq_update_pressure() to fall back to
> using cpuinfo.max_freq as the reference frequency if zero is returned by
> arch_scale_freq_ref().
> 
> Fixes: 75d659317bb1 ("cpufreq: Add a cpufreq pressure feedback for the scheduler")
> Link: https://lore.kernel.org/lkml/CAKfTPtBuRLfYNnR4w--cFZYZy-R8gaPEgVwCcaMmbCcJ2H-muQ@mail.gmail.com/ [1]

This patch achieves the desired behavior for cluster scheduling discussed
in [1]: tasks duly migrate from CPUs of which frequency has been capped.
Tasks spread once the frequency cap is removed.

Tested-by: Ricardo Neri <ricardo.neri-calderon@linux.intel.com> # cluster scheduling

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [PATCH v1] cpufreq: Make cpufreq_update_pressure() fall back to cpuinfo.max_freq
  2026-07-07 17:25 [PATCH v1] cpufreq: Make cpufreq_update_pressure() fall back to cpuinfo.max_freq Rafael J. Wysocki
  2026-07-08  3:44 ` Viresh Kumar
  2026-07-08 17:13 ` Ricardo Neri
@ 2026-07-09 13:00 ` Vincent Guittot
  2 siblings, 0 replies; 5+ messages in thread
From: Vincent Guittot @ 2026-07-09 13:00 UTC (permalink / raw)
  To: Rafael J. Wysocki
  Cc: Linux PM, LKML, Srinivas Pandruvada, Viresh Kumar, Dhruva Gole,
	Lukasz Luba, Qais Yousef, Ingo Molnar

On Tue, 7 Jul 2026 at 19:25, Rafael J. Wysocki <rafael@kernel.org> wrote:
>
> From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
>
> If arch_scale_freq_ref() is not defined for a given arch (like x86, for
> example), cpufreq_update_pressure() will always set cpufreq_pressure to
> zero for all CPUs in the system, which is generally problematic on
> systems with asymmetric capacity [1].
>
> However, in the absence of arch_scale_freq_ref(), it is reasonable
> to assume that cpuinfo.max_freq is the maximum sustainable frequency
> for the given cpufreq policy.  Moreover, there are cases in which
> arch_scale_freq_ref() would need to be defined to return essentially
> the cpuinfo.max_freq value anyway (for example, intel_pstate on
> hybrid platforms).
>
> For the above reasons, update cpufreq_update_pressure() to fall back to
> using cpuinfo.max_freq as the reference frequency if zero is returned by
> arch_scale_freq_ref().
>
> Fixes: 75d659317bb1 ("cpufreq: Add a cpufreq pressure feedback for the scheduler")
> Link: https://lore.kernel.org/lkml/CAKfTPtBuRLfYNnR4w--cFZYZy-R8gaPEgVwCcaMmbCcJ2H-muQ@mail.gmail.com/ [1]
> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

Acked-by: Vincent Guittot <vincent.guittot@linaro.org>

> ---
>  drivers/cpufreq/cpufreq.c |    3 +++
>  1 file changed, 3 insertions(+)
>
> --- a/drivers/cpufreq/cpufreq.c
> +++ b/drivers/cpufreq/cpufreq.c
> @@ -2590,6 +2590,9 @@ static void cpufreq_update_pressure(stru
>
>         cpu = cpumask_first(policy->related_cpus);
>         max_freq = arch_scale_freq_ref(cpu);
> +       if (!max_freq)
> +               max_freq = policy->cpuinfo.max_freq;
> +
>         capped_freq = policy->max;
>
>         /*
>
>
>

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2026-07-09 13:00 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-07-07 17:25 [PATCH v1] cpufreq: Make cpufreq_update_pressure() fall back to cpuinfo.max_freq Rafael J. Wysocki
2026-07-08  3:44 ` Viresh Kumar
2026-07-08  4:09   ` Zhongqiu Han
2026-07-08 17:13 ` Ricardo Neri
2026-07-09 13:00 ` Vincent Guittot

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox