RE: [EXTERNAL] Re: [PATCH v2 2/2] cpufreq/amd-pstate: Fix the scaling_max_freq setting on shared memory CPPC systems

[Jones, Morgan]

Mario,

Confirmed. Thank you for the help! Slightly different refs on my end:

Remotes:

next    https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git (fetch)
next    https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git (push)
origin  git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git (fetch)
origin  git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git (push)
superm1 https://git.kernel.org/pub/scm/linux/kernel/git/superm1/linux.git/ (fetch)
superm1 https://git.kernel.org/pub/scm/linux/kernel/git/superm1/linux.git/ (push)
torvalds        git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git (fetch)
torvalds        git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git (push)

Patches:

git format-patch 12753d71e8c5^..12753d71e8c5
git format-patch f3a052391822b772b4e27f2594526cf1eb103cab^..f3a052391822b772b4e27f2594526cf1eb103cab
git format-patch bf202e654bfa57fb8cf9d93d4c6855890b70b9c4^..bf202e654bfa57fb8cf9d93d4c6855890b70b9c4

Results:

Linux redact 6.6.48 #1-NixOS SMP PREEMPT_DYNAMIC Tue Jan  1 00:00:00 UTC 1980 x86_64 GNU/Linux

analyzing CPU 56:
  driver: amd-pstate-epp
  CPUs which run at the same hardware frequency: 56
  CPUs which need to have their frequency coordinated by software: 56
  maximum transition latency:  Cannot determine or is not supported.
  hardware limits: 400 MHz - 3.35 GHz
  available cpufreq governors: performance powersave
  current policy: frequency should be within 400 MHz and 3.35 GHz.
                  The governor "performance" may decide which speed to use
                  within this range.
  current CPU frequency: Unable to call hardware
  current CPU frequency: 2.09 GHz (asserted by call to kernel)
  boost state support:
    Supported: yes
    Active: yes
    AMD PSTATE Highest Performance: 255. Maximum Frequency: 3.35 GHz.
    AMD PSTATE Nominal Performance: 152. Nominal Frequency: 2.00 GHz.
    AMD PSTATE Lowest Non-linear Performance: 115. Lowest Non-linear Frequency: 1.51 GHz.
    AMD PSTATE Lowest Performance: 31. Lowest Frequency: 400 MHz.

And our builds are back to being fast with `amd_pstate=active amd_prefcore=enable amd_pstate.shared_mem=1`.

Morgan

-----Original Message-----
From: Mario Limonciello <mario.limonciello@xxxxxxx> 
Sent: Thursday, September 5, 2024 8:12 AM
To: Jones, Morgan <Morgan.Jones@xxxxxxxxxx>
Cc: linux-pm@xxxxxxxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx; David Arcari <darcari@xxxxxxxxxx>; Dhananjay Ugwekar <Dhananjay.Ugwekar@xxxxxxx>; rafael@xxxxxxxxxx; viresh.kumar@xxxxxxxxxx; gautham.shenoy@xxxxxxx; perry.yuan@xxxxxxx; skhan@xxxxxxxxxxxxxxxxxxx; li.meng@xxxxxxx; ray.huang@xxxxxxx
Subject: Re: [EXTERNAL] Re: [PATCH v2 2/2] cpufreq/amd-pstate: Fix the scaling_max_freq setting on shared memory CPPC systems

Hi Morgan,

Please apply these 3 commits:

commit 12753d71e8c5 ("ACPI: CPPC: Add helper to get the highest performance value") commit ed429c686b79 ("cpufreq: amd-pstate: Enable amd-pstate preferred core support") commit 3d291fe47fe1 ("cpufreq: amd-pstate: fix the highest frequency issue which limits performance")

The first two should help your system, the third will prevent introducing a regression on a different one.

Assuming that works we should ask @stable to pull all 3 in to fix this regression.

Thanks,

On 9/4/2024 08:57, Mario Limonciello wrote:
> Morgan,
> 
> I was referring specfiically to the version that landed in Linus' tree:
> https://urldefense.us/v3/__https://git.kernel.org/torvalds/c/8164f7433
> 264__;!!C5Asm8uRnZQmlRln!aIZEDEbIUKD7OrxN0b0KjoqKYDL2yMkwk4EK7x_oSnyHQ
> 6MEq7yt6JHjd0TD9DgEYEWDcF58OKL8c7G11bT3dSqL8eM$
> 
> But yeah it's effectively the same thing.  In any case, it's not the 
> solution.
> 
> We had some internal discussion and suspect this is due to missing 
> prefcore patches in 6.6 as that feature landed in 6.9.  We'll try to 
> reproduce this on a Rome system and come back with our findings and 
> suggestions what to do.
> 
> Thanks,
>