From: Jie Zhan <zhanjie9@hisilicon.com>
To: Pengjie Zhang <zhangpengjie2@huawei.com>, <rafael@kernel.org>,
<viresh.kumar@linaro.org>
Cc: <linux-pm@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
<zhenglifeng1@huawei.com>, <lihuisong@huawei.com>,
<yubowen8@huawei.com>, <linhongye@h-partners.com>,
<linuxarm@huawei.com>, <jonathan.cameron@huawei.com>,
<wangzhi12@huawei.com>
Subject: Re: [PATCH v2] cpufreq: cppc: Clamp default minimum limit to lowest_nonlinear_perf
Date: Thu, 5 Mar 2026 21:49:55 +0800 [thread overview]
Message-ID: <cd08cee4-7923-459e-ad75-164c258a189e@hisilicon.com> (raw)
In-Reply-To: <20260213100633.15413-1-zhangpengjie2@huawei.com>
On 2/13/2026 6:06 PM, Pengjie Zhang wrote:
> The ACPI spec defines 'lowest_nonlinear_perf' as the threshold for
> linear performance scaling. Performance levels below this threshold
> are typically inefficient and should not be used by default.
>
> Currently, the QoS minimum request is initialized to 0. This defaults
I'm more curious on the original commit that overrides the policy->min set
by driver, which is:
521223d8b3ec ("cpufreq: Fix initialization of min and max frequency QoS requests")
The changelog says:
"The min and max frequency QoS requests in the cpufreq core are initialized
to whatever the current min and max frequency values are at the init time,
but if any of these values change later (for example, cpuinfo.max_freq is
updated by the driver), these initial request values will be limiting the
CPU frequency unnecessarily unless they are changed by user space via
sysfs."
So, instead of doing what the patch did, what about calling
freq_qos_update_request(policy->max_freq_req, xxx) when cpuinfo.max_freq is
updated?
Jie
> the performance floor to the absolute "Lowest Performance" state
> instead of "lowest_nonlinear_perf", allowing the CPU to operate in
> an inefficient range unnecessarily.
>
> Signed-off-by: Pengjie Zhang <zhangpengjie2@huawei.com>
> ---
> Changes in v2:
> - Renamed the patch subject to better reflect the logic change.
> - Updated the commit log to clarify ACPI spec details.
> Link to v1:https://lore.kernel.org/all/20260116094555.2978887-1-zhangpengjie2@huawei.com/
> ---
> drivers/cpufreq/cppc_cpufreq.c | 18 ++++++++++++++++--
> 1 file changed, 16 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/cpufreq/cppc_cpufreq.c b/drivers/cpufreq/cppc_cpufreq.c
> index 7e8042efedd1..4a3031d9fcf4 100644
> --- a/drivers/cpufreq/cppc_cpufreq.c
> +++ b/drivers/cpufreq/cppc_cpufreq.c
> @@ -333,9 +333,23 @@ static unsigned int cppc_cpufreq_fast_switch(struct cpufreq_policy *policy,
> return target_freq;
> }
>
> -static int cppc_verify_policy(struct cpufreq_policy_data *policy)
> +static int cppc_verify_policy(struct cpufreq_policy_data *policy_data)
> {
> - cpufreq_verify_within_cpu_limits(policy);
> + if (policy_data->min == FREQ_QOS_MIN_DEFAULT_VALUE) {
> + struct cpufreq_policy *policy __free(put_cpufreq_policy) =
> + cpufreq_cpu_get(policy_data->cpu);
> + struct cppc_cpudata *cpu_data;
> +
> + if (!policy)
> + return -EINVAL;
> +
> + cpu_data = policy->driver_data;
> + policy_data->min = cppc_perf_to_khz(&cpu_data->perf_caps,
> + cpu_data->perf_caps.lowest_nonlinear_perf);
> + }
> +
> + cpufreq_verify_within_cpu_limits(policy_data);
> +
> return 0;
> }
>
next prev parent reply other threads:[~2026-03-05 13:50 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-13 10:06 Pengjie Zhang
2026-03-03 12:03 ` zhangpengjie (A)
2026-03-05 6:32 ` Viresh Kumar
2026-03-05 7:00 ` Jie Zhan
2026-03-05 11:31 ` zhenglifeng (A)
2026-03-05 13:14 ` Sumit Gupta
2026-03-06 15:08 ` Pierre Gondois
2026-03-06 18:16 ` Rafael J. Wysocki
2026-03-05 11:34 ` zhenglifeng (A)
2026-03-05 13:49 ` Jie Zhan [this message]
2026-03-09 13:16 ` zhangpengjie (A)
2026-03-10 9:12 ` Jie Zhan
2026-03-10 11:07 ` Pierre Gondois
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=cd08cee4-7923-459e-ad75-164c258a189e@hisilicon.com \
--to=zhanjie9@hisilicon.com \
--cc=jonathan.cameron@huawei.com \
--cc=lihuisong@huawei.com \
--cc=linhongye@h-partners.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=linuxarm@huawei.com \
--cc=rafael@kernel.org \
--cc=viresh.kumar@linaro.org \
--cc=wangzhi12@huawei.com \
--cc=yubowen8@huawei.com \
--cc=zhangpengjie2@huawei.com \
--cc=zhenglifeng1@huawei.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®