linux-kernel - Re: [PATCH 10/11] cpufreq: amd-pstate: fix the highest frequency issue which limit performance

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <5fc36c91-1552-4929-8fac-c76b217e1c03@amd.com>
Date: Tue, 7 May 2024 10:23:30 -0500
From: Mario Limonciello <mario.limonciello@....com>
To: Perry Yuan <perry.yuan@....com>
Cc: Alexander.Deucher@....com, Xinmei.Huang@....com, Xiaojian.Du@....com,
 Li.Meng@....com, linux-pm@...r.kernel.org, linux-kernel@...r.kernel.org,
 rafael.j.wysocki@...el.com, viresh.kumar@...aro.org, Ray.Huang@....com,
 gautham.shenoy@....com, Borislav.Petkov@....com
Subject: Re: [PATCH 10/11] cpufreq: amd-pstate: fix the highest frequency
 issue which limit performance

On 5/7/2024 02:15, Perry Yuan wrote:
> To address the performance drop issue, an optimization has been implemented.
> The incorrect highest performance value previously set by the low-level power
> firmware for AMD CPUs with Family ID 0x19 and Model ID ranging from 0x70 to 0x7F
> series has been identified as the cause.
> 
> To resolve this, a check has been implemented to accurately determine the CPU family
> and model ID. The correct highest performance value is now set and the performance
> drop caused by the incorrect highest performance value are eliminated.
> 
> Before the fix, the highest frequency was set to 4200MHz, now it is set
> to 4971MHz which is correct.
> 
> CPU NODE SOCKET CORE L1d:L1i:L2:L3 ONLINE    MAXMHZ   MINMHZ       MHZ
>    0    0      0    0 0:0:0:0          yes 4971.0000 400.0000  400.0000
>    1    0      0    0 0:0:0:0          yes 4971.0000 400.0000  400.0000
>    2    0      0    1 1:1:1:0          yes 4971.0000 400.0000 4865.8140
>    3    0      0    1 1:1:1:0          yes 4971.0000 400.0000  400.0000
> 
> Closes: https://bugzilla.kernel.org/show_bug.cgi?id=218759
> Signed-off-by: Perry Yuan <perry.yuan@....com>
> ---
>   drivers/cpufreq/amd-pstate.c | 8 ++++++++
>   1 file changed, 8 insertions(+)
> 
> diff --git a/drivers/cpufreq/amd-pstate.c b/drivers/cpufreq/amd-pstate.c
> index 7fe8a8fc6227..3ff381c4edf7 100644
> --- a/drivers/cpufreq/amd-pstate.c
> +++ b/drivers/cpufreq/amd-pstate.c
> @@ -348,6 +348,7 @@ static u32 amd_pstate_highest_perf_set(struct amd_cpudata *cpudata)
>   {
>   	u32 highest_perf;
>   	int core_type;
> +	struct cpuinfo_x86 *c = &cpu_data(0);
>   
>   	core_type = amd_pstate_get_cpu_type(cpudata->cpu);
>   	pr_debug("core_type %d found\n", core_type);
> @@ -355,6 +356,13 @@ static u32 amd_pstate_highest_perf_set(struct amd_cpudata *cpudata)
>   	switch (core_type) {
>   	case CPU_CORE_TYPE_NO_HETERO_SUP:
>   		highest_perf = CPPC_HIGHEST_PERF_DEFAULT;
> +		/*
> +		 * For AMD CPUs with Family ID 19H and Model ID range 0x70 to 0x7F,
> +		 * the highest performance level is set to 196.
> +		 * https://bugzilla.kernel.org/show_bug.cgi?id=218759
> +		 */
> +		if (c->x86 == 0x19 && (c->x86_model >= 0x70 && c->x86_model <= 0x7F))
> +			highest_perf = CPPC_HIGHEST_PERF_PERFORMANCE;

I agree this is the right type of change to make for the reported issue, 
but since it's actually a performance regression from 6.9, can you move 
this to the start of the series and add a Fixes tag and stable tag so we 
can get the regression fixed for 6.10 and 6.9.y?

This will of course mean you need to adjust patch 9 as well for such a 
change, but I think it's better this specific patch goes into 6.10 as a 
fix and the rest of the series can aim for 6.11.

>   		break;
>   	case CPU_CORE_TYPE_PERFORMANCE:
>   		highest_perf = CPPC_HIGHEST_PERF_PERFORMANCE;