Re: [PATCH v2] cpufreq: Handle CPUFREQ_ETERNAL with a default transition latency

[Zhongqiu Han]

On 9/22/2025 8:59 PM, Shawn Guo wrote:
> From: Shawn Guo <shawnguo@xxxxxxxxxx>
>
> A regression is seen with 6.6 -> 6.12 kernel upgrade on platforms where
> cpufreq-dt driver sets cpuinfo.transition_latency as CPUFREQ_ETERNAL (-1),
> due to that platform's DT doesn't provide the optional property
> 'clock-latency-ns'.  The dbs sampling_rate was 10000 us on 6.6 and
> suddently becomes 6442450 us (4294967295 / 1000 * 1.5) on 6.12 for these
> platforms, because the default transition delay was dropped by the commits
> below.
>
>    commit 37c6dccd6837 ("cpufreq: Remove LATENCY_MULTIPLIER")
>    commit a755d0e2d41b ("cpufreq: Honour transition_latency over transition_delay_us")
Hello Shawn,

Reported by checkpatch.pl:
WARNING: Prefer a maximum 75 chars per line (possible unwrapped commit
description?)
#12:
  commit a755d0e2d41b ("cpufreq: Honour transition_latency over
transition_delay_us")


>    commit e13aa799c2a6 ("cpufreq: Change default transition delay to 2ms")
>
> It slows down dbs governor's reacting to CPU loading change
> dramatically.  Also, as transition_delay_us is used by schedutil governor
> as rate_limit_us, it shows a negative impact on device idle power
> consumption, because the device gets slightly less time in the lowest OPP.
>
> Fix the regressions by defining a default transition latency for
> handling the case of CPUFREQ_ETERNAL.
>
> Cc: stable@xxxxxxxxxxxxxxx
> Fixes: 37c6dccd6837 ("cpufreq: Remove LATENCY_MULTIPLIER")
> Signed-off-by: Shawn Guo <shawnguo@xxxxxxxxxx>
> ---
> Changes for v2:
> - Follow Rafael's suggestion to define a default transition latency for
>    handling CPUFREQ_ETERNAL, and pave the way to get rid of
>    CPUFREQ_ETERNAL completely later.
>
> v1: https://lkml.org/lkml/2025/9/10/294
>
>   drivers/cpufreq/cpufreq.c | 3 +++
>   include/linux/cpufreq.h   | 2 ++
>   2 files changed, 5 insertions(+)
>
> diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
> index fc7eace8b65b..c69d10f0e8ec 100644
> --- a/drivers/cpufreq/cpufreq.c
> +++ b/drivers/cpufreq/cpufreq.c
> @@ -549,6 +549,9 @@ unsigned int cpufreq_policy_transition_delay_us(struct cpufreq_policy *policy)
>   	if (policy->transition_delay_us)
>   		return policy->transition_delay_us;
>   
> +	if (policy->cpuinfo.transition_latency == CPUFREQ_ETERNAL)
> +		policy->cpuinfo.transition_latency = CPUFREQ_DEFAULT_TANSITION_LATENCY_NS;

For the fallback case, May we print a dbg info in dmesg to inform
developers that the device tree is missing the clock-latency-ns
property? (Rafael can help comment~)


> +
>   	latency = policy->cpuinfo.transition_latency / NSEC_PER_USEC;
>   	if (latency)
>   		/* Give a 50% breathing room between updates */
> diff --git a/include/linux/cpufreq.h b/include/linux/cpufreq.h
> index 95f3807c8c55..935e9a660039 100644
> --- a/include/linux/cpufreq.h
> +++ b/include/linux/cpufreq.h
> @@ -36,6 +36,8 @@
>   /* Print length for names. Extra 1 space for accommodating '\n' in prints */
>   #define CPUFREQ_NAME_PLEN		(CPUFREQ_NAME_LEN + 1)
>   
> +#define CPUFREQ_DEFAULT_TANSITION_LATENCY_NS	NSEC_PER_MSEC
> +

TANSITION --> TRANSITION ?


>   struct cpufreq_governor;
>   
>   enum cpufreq_table_sorting {


--
Thx and BRs,
Zhongqiu Han