[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1dd930a0-b975-4302-9e1f-f06904d8a25c@oss.qualcomm.com>
Date: Mon, 22 Sep 2025 21:45:12 +0800
From: Zhongqiu Han <zhongqiu.han@....qualcomm.com>
To: Shawn Guo <shawnguo2@...h.net>, "Rafael J . Wysocki" <rafael@...nel.org>
Cc: Shawn Guo <shawnguo@...nel.org>, Qais Yousef <qyousef@...alina.io>,
Viresh Kumar <viresh.kumar@...aro.org>, linux-pm@...r.kernel.org,
linux-kernel@...r.kernel.org, stable@...r.kernel.org,
zhongqiu.han@....qualcomm.com
Subject: Re: [PATCH v2] cpufreq: Handle CPUFREQ_ETERNAL with a default
transition latency
On 9/22/2025 8:59 PM, Shawn Guo wrote:
> From: Shawn Guo <shawnguo@...nel.org>
>
> 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@...r.kernel.org
> Fixes: 37c6dccd6837 ("cpufreq: Remove LATENCY_MULTIPLIER")
> Signed-off-by: Shawn Guo <shawnguo@...nel.org>
> ---
> 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
Powered by blists - more mailing lists