It seems that preferred cores functionality stopped working for Zen3 since kernel 6.12.6 (works OK using 6.12.5-2 or earlier).
Tested on 5950x with linux-cachyos and linux-cachyos-bore v3 flavours, amd-pstate-epp driver.
Steps to reproduce:
use ryzen_monitor or some kind of system monitor to see which cores are being utilized
run “stress - c 2” or other software causing low-thread workload.
In my case, best cores are 1,7 and 9 and are properly selected using kernel version 6.12.5-2 or earlier. On newer kernels, it seems to pick up other (random?) cores on subsequent “stress” runs (also with other thread numbers). This is also true for other software (like python).
CPU is 5950x, undervolted using per-core PBO and voltage offset, capped at 4750mhz max. B550 chipset and 128GB RAM (four banks of dual rank mem).
Please let me know if any other information is helpful.
The previous test build only confirmed that the recent changes caused breakage. There were 3 commits in total queued between 6.12.5 and 6.12.6, and atleast one of them caused it. If you can, please try Nginx Directory -2 build of the test kernel.
39311a230e04eab2fe7e257ad79922040bfdaf1c is the first bad commit
commit 39311a230e04eab2fe7e257ad79922040bfdaf1c
Author: Mario Limonciello <mario.limonciello@amd.com>
Date: Mon Dec 9 12:52:34 2024 -0600
cpufreq/amd-pstate: Store the boost numerator as highest perf again
commit ad4caad58d91d ("cpufreq: amd-pstate: Merge
amd_pstate_highest_perf_set() into amd_get_boost_ratio_numerator()")
changed the semantics for highest perf and commit 18d9b52271213
("cpufreq/amd-pstate: Use nominal perf for limits when boost is disabled")
worked around those semantic changes.
This however is a confusing result and furthermore makes it awkward to
change frequency limits and boost due to the scaling differences. Restore
the boost numerator to highest perf again.
Suggested-by: Dhananjay Ugwekar <Dhananjay.Ugwekar@amd.com>
Reviewed-by: Gautham R. Shenoy <gautham.shenoy@amd.com>
Fixes: ad4caad58d91 ("cpufreq: amd-pstate: Merge amd_pstate_highest_perf_set() into amd_get_boost_ratio_numerator()")
Link: https://lore.kernel.org/r/20241209185248.16301-2-mario.limonciello@amd.com
Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
Documentation/admin-guide/pm/amd-pstate.rst | 4 +---
drivers/cpufreq/amd-pstate.c | 25 +++++++++++++++----------
2 files changed, 16 insertions(+), 13 deletions(-)
I will report this to AMD. To assist with that please sendthe output of cat /sys/devices/system/cpu/cpu*/cpufreq/amd_pstate_prefcore_ranking.
edit: Did the rc kernel behave as expected or is it broken there too?
Yes, the 6.13.0-rc4-1-cachyos-rc kernel is affected too.
Even if perfcore works, it seems to be much worse than the old algorithm.
Below I paste the result from the command you asked (same for all kernels), as well as example core usage for different kernels for “stress -c 4” command.
Hardware is 5950x, undervolted and underclocked. Limited to max 4750Mhz and 80C. Kernel 6.12.7-4-cachyos-test and 6.12.5-2-cachyos gave me exactly the same result.
[parsec Pulpit]# cat /sys/devices/system/cpu/cpu*/cpufreq/amd_pstate_prefcore_ranking
211
181
196
171
186
176
191
211
236
231
206
236
216
221
226
236
166
201
181
196
171
186
231
176
191
206
216
221
226
236
166
201
Linux parsec 6.12.7-4-cachyos-test #1 SMP PREEMPT_DYNAMIC Sun, 29 Dec 2024 16:20:51 +0000 x86_64 GNU/Linux
OR
Linux parsec 6.12.5-2-cachyos #1 SMP PREEMPT_DYNAMIC Sun, 15 Dec 2024 09:12:45 +0000 x86_64 GNU/Linux
(exactly the same result)
│ Core 0 │ Sleeping | 1.876 W | 1.344 V | 53.88 C | C0: 1.2 % | C1: 98.8 % | C6: 0.0 % │
│ Core 1 │ 4750 MHz | 9.386 W | 1.344 V | 71.04 C | C0: 100.0 % | C1: 0.0 % | C6: 0.0 % │
│ Core 2 │ 4750 MHz | 9.459 W | 1.344 V | 72.05 C | C0: 100.0 % | C1: 0.0 % | C6: 0.0 % │
│ Core 3 │ Sleeping | 0.167 W | 0.252 V | 51.51 C | C0: 0.1 % | C1: 4.4 % | C6: 95.5 % │
│ Core 4 │ Sleeping | 0.325 W | 0.292 V | 54.53 C | C0: 1.0 % | C1: 7.1 % | C6: 91.9 % │
│ Core 5 │ Sleeping | 0.396 W | 0.392 V | 51.69 C | C0: 0.4 % | C1: 16.4 % | C6: 83.2 % │
│ Core 6 │ 4750 MHz | 9.493 W | 1.344 V | 72.43 C | C0: 100.0 % | C1: 0.0 % | C6: 0.0 % │
│ Core 7 │ 4750 MHz | 9.411 W | 1.344 V | 71.37 C | C0: 100.0 % | C1: 0.0 % | C6: 0.0 % │
│ Core 8 │ Sleeping | 0.040 W | 0.207 V | 43.11 C | C0: 0.0 % | C1: 0.6 % | C6: 99.4 % │
│ Core 9 │ Sleeping | 0.030 W | 0.200 V | 38.60 C | C0: 0.0 % | C1: 0.0 % | C6: 100.0 % │
│ Core 10 │ Sleeping | 0.085 W | 0.265 V | 42.94 C | C0: 0.1 % | C1: 5.6 % | C6: 94.3 % │
│ Core 11 │ Sleeping | 0.042 W | 0.209 V | 38.66 C | C0: 0.1 % | C1: 0.7 % | C6: 99.2 % │
│ Core 12 │ Sleeping | 0.035 W | 0.201 V | 42.66 C | C0: 0.0 % | C1: 0.0 % | C6: 99.9 % │
│ Core 13 │ Sleeping | 0.040 W | 0.210 V | 38.55 C | C0: 0.1 % | C1: 0.8 % | C6: 99.1 % │
│ Core 14 │ Sleeping | 0.075 W | 0.255 V | 42.32 C | C0: 0.0 % | C1: 4.8 % | C6: 95.2 % │
│ Core 15 │ Sleeping | 0.030 W | 0.201 V | 38.41 C | C0: 0.0 % | C1: 0.0 % | C6: 99.9 %
Linux parsec 6.13.0-rc4-1-cachyos-rc #1 SMP PREEMPT_DYNAMIC Wed, 25 Dec 2024 21:57:58 +0000 x86_64 GNU/Linux
│ Core 0 │ 4595 MHz | 11.334 W | 1.437 V | 75.04 C | C0: 100.0 % | C1: 0.0 % | C6: 0.0 % │
│ Core 1 │ Sleeping | 0.462 W | 0.412 V | 49.75 C | C0: 0.2 % | C1: 17.0 % | C6: 82.9 % │
│ Core 2 │ Sleeping | 0.181 W | 0.241 V | 49.99 C | C0: 0.2 % | C1: 3.1 % | C6: 96.7 % │
│ Core 3 │ Sleeping | 0.349 W | 0.334 V | 51.29 C | C0: 0.4 % | C1: 10.4 % | C6: 89.1 % │
│ Core 4 │ Sleeping | 0.459 W | 0.406 V | 46.38 C | C0: 0.8 % | C1: 15.9 % | C6: 83.3 % │
│ Core 5 │ Sleeping | 0.159 W | 0.223 V | 54.33 C | C0: 0.1 % | C1: 1.8 % | C6: 98.1 % │
│ Core 6 │ Sleeping | 0.148 W | 0.212 V | 45.00 C | C0: 0.6 % | C1: 0.3 % | C6: 99.1 % │
│ Core 7 │ 4595 MHz | 11.741 W | 1.437 V | 79.06 C | C0: 100.0 % | C1: 0.0 % | C6: 0.0 % │
│ Core 8 │ Sleeping | 0.512 W | 0.649 V | 50.47 C | C0: 0.6 % | C1: 35.7 % | C6: 63.7 % │
│ Core 9 │ Sleeping | 0.078 W | 0.227 V | 39.83 C | C0: 0.3 % | C1: 1.8 % | C6: 97.9 % │
│ Core 10 │ 4595 MHz | 9.510 W | 1.437 V | 75.03 C | C0: 100.0 % | C1: 0.0 % | C6: 0.0 % │
│ Core 11 │ Sleeping | 0.395 W | 0.544 V | 40.71 C | C0: 2.9 % | C1: 24.9 % | C6: 72.2 % │
│ Core 12 │ 4595 MHz | 9.482 W | 1.437 V | 74.36 C | C0: 100.0 % | C1: 0.0 % | C6: 0.0 % │
│ Core 13 │ Sleeping | 0.764 W | 0.998 V | 41.19 C | C0: 2.4 % | C1: 62.1 % | C6: 35.5 % │
│ Core 14 │ Sleeping | 0.346 W | 0.415 V | 49.18 C | C0: 1.5 % | C1: 15.9 % | C6: 82.7 % │
│ Core 15 │ Sleeping | 0.383 W | 0.465 V | 40.61 C | C0: 2.1 % | C1: 19.3 % | C6: 78.6 %
Hi, big thanks for the detailed report. Since the AMD developer is away for a while, could you possibly report this bug in https://bugzilla.kernel.org/ with the information I’m replying to + the bisected commit.
Please also provide information from running amd-pstate-triage.py, ideally from both affected and non-affected kernels.
Note: If you can’t open a thread in kernel bugzilla, I can do it for you
Thank you so much. This report is very detailed and it should be sufficient, but if there’s anything missing Mario should let you know. I think this marks the end of me playing a role as the middleman, I’ll be watching the bugzilla too and will come back and provide you with test kernels when there’s a proposed fix
This is interesting because i also have the same CPU undervolted with a negative voltage offset + Curve Optimizer and boost (4800Mhz) and max temp capped like you.
I have always had the preferred cores option disabled in the bios since both Windows and Linux seem to work just the opposite of how it should by choosing the most power-hungry cores as the most used ones.
By deactivating it I notice that the system is more fluid as the loads are distributed among all the cores and not always the same ones. Being capped, all my cores are equally fast and as “preferred cores” it never chooses the ones that consume less, there is no sense in having this option activated.
I am using amd_pstate=passive and the system feels smoother. You might want to try it.
Seems to be working fine (power draw is even lower than before, but this is probably due to the fact that the rig is cold now - less current leakage)
Linux version 6.12.7-5-cachyos-test (linux-cachyos-test@cachyos) (clang version 18.1.8, LLD 18.1.8) #1 SMP PREEMPT_DYNAMIC Thu, 02 Jan 2025 09:27:15 +0000
│ Core 0 │ Sleeping | 1.848 W | 1.325 V | 49.62 C | C0: 3.2 % | C1: 96.8 % | C6: 0.0 % │
│ Core 1 │ 4750 MHz | 8.691 W | 1.325 V | 65.41 C | C0: 100.0 % | C1: 0.0 % | C6: 0.0 % │
│ Core 2 │ 4750 MHz | 8.749 W | 1.325 V | 66.34 C | C0: 100.0 % | C1: 0.0 % | C6: 0.0 % │
│ Core 3 │ Sleeping | 0.699 W | 0.598 V | 47.98 C | C0: 1.2 % | C1: 34.2 % | C6: 64.6 % │
│ Core 4 │ Sleeping | 0.357 W | 0.353 V | 50.10 C | C0: 0.9 % | C1: 12.7 % | C6: 86.4 % │
│ Core 5 │ Sleeping | 0.320 W | 0.330 V | 47.51 C | C0: 1.2 % | C1: 10.3 % | C6: 88.4 % │
│ Core 6 │ 4750 MHz | 8.778 W | 1.325 V | 66.78 C | C0: 100.0 % | C1: 0.0 % | C6: 0.0 % │
│ Core 7 │ 4750 MHz | 8.709 W | 1.325 V | 65.68 C | C0: 100.0 % | C1: 0.0 % | C6: 0.0 % │
│ Core 8 │ Sleeping | 0.036 W | 0.204 V | 39.22 C | C0: 0.1 % | C1: 0.3 % | C6: 99.6 % │
│ Core 9 │ Sleeping | 0.026 W | 0.200 V | 34.78 C | C0: 0.0 % | C1: 0.0 % | C6: 100.0 % │
│ Core 10 │ Sleeping | 0.030 W | 0.200 V | 39.01 C | C0: 0.0 % | C1: 0.0 % | C6: 100.0 % │
│ Core 11 │ Sleeping | 0.027 W | 0.201 V | 34.86 C | C0: 0.1 % | C1: 0.1 % | C6: 99.9 % │
│ Core 12 │ Sleeping | 0.029 W | 0.200 V | 38.71 C | C0: 0.0 % | C1: 0.0 % | C6: 100.0 % │
│ Core 13 │ Sleeping | 0.039 W | 0.217 V | 34.82 C | C0: 0.1 % | C1: 1.5 % | C6: 98.5 % │
│ Core 14 │ Sleeping | 0.029 W | 0.200 V | 38.34 C | C0: 0.0 % | C1: 0.0 % | C6: 100.0 % │
│ Core 15 │ Sleeping | 0.035 W | 0.216 V | 34.71 C | C0: 0.0 % | C1: 1.4 % | C6: 98.6 % │
@XXX Yes, I was targeting 4800Mhz too but it caused rare errors in dmesg on fastest cores, and I was too lazy to stabilize it :D. Thanks for suggestion, I may try disabled preferred cores, but there seems to be quite significant difference between my better and worse cores (and CCD1 and 2), and it is clearly audible in such workload cases (my cpu is passively cooled until it reaches 50C). WIth preferred cores working, CCD1 is preferred and the rig works much more quiet.
