From: Shawn Guo <shawnguo2@yeah.net>
To: "Rafael J. Wysocki" <rafael@kernel.org>
Cc: Linux PM <linux-pm@vger.kernel.org>,
Shawn Guo <shawnguo@kernel.org>,
Qais Yousef <qyousef@layalina.io>,
LKML <linux-kernel@vger.kernel.org>,
Viresh Kumar <viresh.kumar@linaro.org>,
Pierre Gondois <pierre.gondois@arm.com>,
Mario Limonciello <mario.limonciello@amd.com>,
Linux ACPI <linux-acpi@vger.kernel.org>,
Jie Zhan <zhanjie9@hisilicon.com>,
rust-for-linux@vger.kernel.org, Miguel Ojeda <ojeda@kernel.org>,
Alex Gaynor <alex.gaynor@gmail.com>
Subject: Re: [PATCH v3 1/4] cpufreq: Make drivers using CPUFREQ_ETERNAL specify transition latency
Date: Sun, 28 Sep 2025 11:23:57 +0800 [thread overview]
Message-ID: <aNiqTYZai83Yguqt@dragon> (raw)
In-Reply-To: <2264949.irdbgypaU6@rafael.j.wysocki>
On Fri, Sep 26, 2025 at 12:12:37PM +0200, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
>
> Commit a755d0e2d41b ("cpufreq: Honour transition_latency over
> transition_delay_us") caused platforms where cpuinfo.transition_latency
> is CPUFREQ_ETERNAL to get a very large transition latency whereas
> previously it had been capped at 10 ms (and later at 2 ms).
>
> This led to a user-observable regression between 6.6 and 6.12 as
> described by Shawn:
>
> "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 [...].
>
> 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."
>
> Evidently, the expectation of the drivers using CPUFREQ_ETERNAL as
> cpuinfo.transition_latency was that it would be capped by the core,
> but they may as well return a default transition latency value instead
> of CPUFREQ_ETERNAL and the core need not do anything with it.
>
> Accordingly, introduce CPUFREQ_DEFAULT_TRANSITION_LATENCY_NS and make
> all of the drivers in question use it instead of CPUFREQ_ETERNAL. Also
> update the related Rust binding.
>
> Fixes: a755d0e2d41b ("cpufreq: Honour transition_latency over transition_delay_us")
> Closes: https://lore.kernel.org/linux-pm/20250922125929.453444-1-shawnguo2@yeah.net/
> Reported-by: Shawn Guo <shawnguo@kernel.org>
> Reviewed-by: Mario Limonciello (AMD) <superm1@kernel.org>
> Reviewed-by: Jie Zhan <zhanjie9@hisilicon.com>
> Cc: 6.6+ <stable@vger.kernel.org> # 6.6+
> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> ---
>
> v1 -> v3:
> * Add updates of the Rust version of cpufreq-dt and Rust binding
> * Update the changelog
> * Add tags from Mario Limonciello and Jie Zhan
>
> ---
> drivers/cpufreq/cpufreq-dt.c | 2 +-
> drivers/cpufreq/imx6q-cpufreq.c | 2 +-
> drivers/cpufreq/mediatek-cpufreq-hw.c | 2 +-
> drivers/cpufreq/rcpufreq_dt.rs | 2 +-
> drivers/cpufreq/scmi-cpufreq.c | 2 +-
> drivers/cpufreq/scpi-cpufreq.c | 2 +-
> drivers/cpufreq/spear-cpufreq.c | 2 +-
> include/linux/cpufreq.h | 3 +++
> rust/kernel/cpufreq.rs | 7 ++++---
> 9 files changed, 14 insertions(+), 10 deletions(-)
>
> --- a/drivers/cpufreq/cpufreq-dt.c
> +++ b/drivers/cpufreq/cpufreq-dt.c
> @@ -104,7 +104,7 @@ static int cpufreq_init(struct cpufreq_p
>
> transition_latency = dev_pm_opp_get_max_transition_latency(cpu_dev);
> if (!transition_latency)
> - transition_latency = CPUFREQ_ETERNAL;
> + transition_latency = CPUFREQ_DEFAULT_TRANSITION_LATENCY_NS;
>
> cpumask_copy(policy->cpus, priv->cpus);
> policy->driver_data = priv;
> --- a/drivers/cpufreq/imx6q-cpufreq.c
> +++ b/drivers/cpufreq/imx6q-cpufreq.c
> @@ -442,7 +442,7 @@ soc_opp_out:
> }
>
> if (of_property_read_u32(np, "clock-latency", &transition_latency))
> - transition_latency = CPUFREQ_ETERNAL;
> + transition_latency = CPUFREQ_DEFAULT_TRANSITION_LATENCY_NS;
>
> /*
> * Calculate the ramp time for max voltage change in the
> --- a/drivers/cpufreq/mediatek-cpufreq-hw.c
> +++ b/drivers/cpufreq/mediatek-cpufreq-hw.c
> @@ -309,7 +309,7 @@ static int mtk_cpufreq_hw_cpu_init(struc
>
> latency = readl_relaxed(data->reg_bases[REG_FREQ_LATENCY]) * 1000;
> if (!latency)
> - latency = CPUFREQ_ETERNAL;
> + latency = CPUFREQ_DEFAULT_TRANSITION_LATENCY_NS;
>
> policy->cpuinfo.transition_latency = latency;
> policy->fast_switch_possible = true;
> --- a/drivers/cpufreq/rcpufreq_dt.rs
> +++ b/drivers/cpufreq/rcpufreq_dt.rs
> @@ -123,7 +123,7 @@ impl cpufreq::Driver for CPUFreqDTDriver
>
> let mut transition_latency = opp_table.max_transition_latency_ns() as u32;
> if transition_latency == 0 {
> - transition_latency = cpufreq::ETERNAL_LATENCY_NS;
> + transition_latency = cpufreq::DEFAULT_TRANSITION_LATENCY_NS;
> }
>
> policy
> --- a/drivers/cpufreq/scmi-cpufreq.c
> +++ b/drivers/cpufreq/scmi-cpufreq.c
> @@ -294,7 +294,7 @@ static int scmi_cpufreq_init(struct cpuf
>
> latency = perf_ops->transition_latency_get(ph, domain);
> if (!latency)
> - latency = CPUFREQ_ETERNAL;
> + latency = CPUFREQ_DEFAULT_TRANSITION_LATENCY_NS;
>
> policy->cpuinfo.transition_latency = latency;
>
> --- a/drivers/cpufreq/scpi-cpufreq.c
> +++ b/drivers/cpufreq/scpi-cpufreq.c
> @@ -157,7 +157,7 @@ static int scpi_cpufreq_init(struct cpuf
>
> latency = scpi_ops->get_transition_latency(cpu_dev);
> if (!latency)
> - latency = CPUFREQ_ETERNAL;
> + latency = CPUFREQ_DEFAULT_TRANSITION_LATENCY_NS;
>
> policy->cpuinfo.transition_latency = latency;
>
> --- a/drivers/cpufreq/spear-cpufreq.c
> +++ b/drivers/cpufreq/spear-cpufreq.c
> @@ -182,7 +182,7 @@ static int spear_cpufreq_probe(struct pl
>
> if (of_property_read_u32(np, "clock-latency",
> &spear_cpufreq.transition_latency))
> - spear_cpufreq.transition_latency = CPUFREQ_ETERNAL;
> + spear_cpufreq.transition_latency = CPUFREQ_DEFAULT_TRANSITION_LATENCY_NS;
>
> cnt = of_property_count_u32_elems(np, "cpufreq_tbl");
> if (cnt <= 0) {
> --- a/include/linux/cpufreq.h
> +++ b/include/linux/cpufreq.h
> @@ -32,6 +32,9 @@
> */
>
> #define CPUFREQ_ETERNAL (-1)
> +
> +#define CPUFREQ_DEFAULT_TANSITION_LATENCY_NS NSEC_PER_MSEC
Typo of TANSITION, should be CPUFREQ_DEFAULT_TRANSITION_LATENCY_NS.
Shawn
> +
> #define CPUFREQ_NAME_LEN 16
> /* Print length for names. Extra 1 space for accommodating '\n' in prints */
> #define CPUFREQ_NAME_PLEN (CPUFREQ_NAME_LEN + 1)
> --- a/rust/kernel/cpufreq.rs
> +++ b/rust/kernel/cpufreq.rs
> @@ -39,7 +39,8 @@ use macros::vtable;
> const CPUFREQ_NAME_LEN: usize = bindings::CPUFREQ_NAME_LEN as usize;
>
> /// Default transition latency value in nanoseconds.
> -pub const ETERNAL_LATENCY_NS: u32 = bindings::CPUFREQ_ETERNAL as u32;
> +pub const DEFAULT_TRANSITION_LATENCY_NS: u32 =
> + bindings::CPUFREQ_DEFAULT_TRANSITION_LATENCY_NS as u32;
>
> /// CPU frequency driver flags.
> pub mod flags {
> @@ -400,13 +401,13 @@ impl TableBuilder {
> /// The following example demonstrates how to create a CPU frequency table.
> ///
> /// ```
> -/// use kernel::cpufreq::{ETERNAL_LATENCY_NS, Policy};
> +/// use kernel::cpufreq::{DEFAULT_TRANSITION_LATENCY_NS, Policy};
> ///
> /// fn update_policy(policy: &mut Policy) {
> /// policy
> /// .set_dvfs_possible_from_any_cpu(true)
> /// .set_fast_switch_possible(true)
> -/// .set_transition_latency_ns(ETERNAL_LATENCY_NS);
> +/// .set_transition_latency_ns(DEFAULT_TRANSITION_LATENCY_NS);
> ///
> /// pr_info!("The policy details are: {:?}\n", (policy.cpu(), policy.cur()));
> /// }
>
>
>
next prev parent reply other threads:[~2025-09-28 3:24 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-26 10:04 [PATCH v3 0/4] cpufreq: Fixes and cleanups related to CPUFREQ_ETERNAL Rafael J. Wysocki
2025-09-26 10:12 ` [PATCH v3 1/4] cpufreq: Make drivers using CPUFREQ_ETERNAL specify transition latency Rafael J. Wysocki
2025-09-28 3:23 ` Shawn Guo [this message]
2025-09-28 10:00 ` Rafael J. Wysocki
2025-09-29 3:14 ` Shawn Guo
2025-10-01 10:38 ` Qais Yousef
2025-09-26 10:19 ` [PATCH v3 2/4] cpufreq: CPPC: Avoid using CPUFREQ_ETERNAL as transition delay Rafael J. Wysocki
2025-09-28 1:59 ` Jie Zhan
2025-09-26 10:29 ` [PATCH v3 3/4] ACPI: CPPC: Do not use CPUFREQ_ETERNAL as an error value Rafael J. Wysocki
2025-09-26 10:31 ` [PATCH v3 4/4] cpufreq: Drop unused symbol CPUFREQ_ETERNAL Rafael J. Wysocki
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aNiqTYZai83Yguqt@dragon \
--to=shawnguo2@yeah.net \
--cc=alex.gaynor@gmail.com \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=mario.limonciello@amd.com \
--cc=ojeda@kernel.org \
--cc=pierre.gondois@arm.com \
--cc=qyousef@layalina.io \
--cc=rafael@kernel.org \
--cc=rust-for-linux@vger.kernel.org \
--cc=shawnguo@kernel.org \
--cc=viresh.kumar@linaro.org \
--cc=zhanjie9@hisilicon.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.