Also, the “preferred core” patch by the AMD guy is still under review. Currently it’s going with Version 4.
The YouTube video is about some “bugs” that YouTuber found in this patch still being reviewed. It might go through a couple of versions that we don’t know. But what we’re sure it’s that it’s not ready for merge yet, let alone being merged into Linux 6.6.
Sorry to be blunt but what you had just done is worse than “trash talk”
Wow. You REALLY have an issue with semantics, don’t you.
I was not trying to state that the YT exact code change was what was implemented finally in the git pull.
All I intended to confer was that the YT demonstrated that the existing code for preferred_cores was not being correctly enabled.
How and why I do not know as I can’t read code. I do know that an exclamation point in an expression is a NOTing function.
I did not watch the entire YT video in real time. I got the gist of what he was trying to explain ignoring his unnecessary exasperations and skipped to the end until I found the screen shot of the removal of the exclamation point.
And I know for a fact that on my 7950X I had not observed any change from the stock 166 core values for all cores after I had enabled the kernel command line tag also.
The YT example showed the same thing I observed. Since it didn’t do anything in my case, I just removed the tag and moved on.
I just found his YT video a plausible explanation of why the tag didn’t seem to work or do anything.
Have you found the exact code changes by Meng Li yet?
I would like to review it and see exactly what the code changed for my curiosity.
I don’t have any problem with the YT video even it it incorrectly in the end didn’t provide the exact correct code fix. It just demonstrated exactly what I had already observed.
Have good day, KeithMyers.
I don’t think so. Here is the un-patched 6.4–6.5 kernel code:
highest_perf = amd_get_highest_perf();
if (highest_perf > AMD_CPPC_HIGHEST_PERF(cap1))
highest_perf = AMD_CPPC_HIGHEST_PERF(cap1);
WRITE_ONCE(cpudata->highest_perf, highest_perf);
So you can see that without the prefcore enhancement—i.e. before the patch is applied—the default behavior is to assert an upper bound on the highest perf using the AMD_CPPC_HIGHEST_PERF macro. The v1 prefcore patch (mostly) maintains that behavior:
- highest_perf = amd_get_highest_perf();
- if (highest_perf > AMD_CPPC_HIGHEST_PERF(cap1))
- highest_perf = AMD_CPPC_HIGHEST_PERF(cap1);
-
- WRITE_ONCE(cpudata->highest_perf, highest_perf);
+ if (!prefcore_enabled)
+ WRITE_ONCE(cpudata->highest_perf, AMD_CPPC_HIGHEST_PERF(cap1));
+ else
+ WRITE_ONCE(cpudata->highest_perf, AMD_PSTATE_PREFCORE_THRESHOLD);
(I don’t know why it bypasses the amd_get_highest_perf function, but it’s still capped using the AMD_CPPC_HIGHEST_PERF macro if prefcore is not enabled.)
The v2 prefcore patch does negate the conditional expression, but it also swaps the logic:
- highest_perf = amd_get_highest_perf();
- if (highest_perf > cppc_perf.highest_perf)
- highest_perf = cppc_perf.highest_perf;
-
- WRITE_ONCE(cpudata->highest_perf, highest_perf);
+ if (prefcore)
+ WRITE_ONCE(cpudata->highest_perf, AMD_PSTATE_PREFCORE_THRESHOLD);
+ else
+ WRITE_ONCE(cpudata->highest_perf, cppc_perf.highest_perf);
Either way, if prefcore is enabled, it uses AMD_PSTATE_PREFCORE_THRESHOLD instead.
Hi!
After read, and re-read all over and again: I join this forum. So before few days I buy 5900X with 2*8 GB DDR4 at 3200 . Motherboard is Aorus Elite B450 V2 with latest BIOS F65.
So I install Debain 12 , get latest kernel ( 6.4.0.3) and try to setup my 5900X at 3800Mhz ( very light overclock) with as much as possible lower voltage ( now it is at 1.08125V)
I have few AMD CPU and every ( until 5900X) was setup easy. But if I use 5900X at 100% ( with mprime) then it drops to 3300 and stay there.
So I tray with Pstate amd driver and try over few days but cannot get it work and it is never loaded. I try all suggestions here without any success. so maybe it is Debain12 problem?
grub line
GRUB_CMDLINE_LINUX_DEFAULT=“amd_pstate=guided quiet”
CPPC in BIOS enabled
cat /sys/devices/system/cpu/amd-pstate/status
cat: /sys/devices/system/cpu/amd-pstate/status: No such file or directory
Disabling X2APIC
Cannot disable, have AUTO,X2APIC , APIC and compability mode
any other suggestion?
I’d first make sure you are actually running amd_pstate driver.
cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_driver
The 3300Mhz clock I believe is the default of the acpi-cpufreq driver.
Why don’t you try the basic version of amd_pstate first.
amd_pstate=passive
and check after reboot whether the driver is now amd_pstate.
I can’t remember exactly where the transition in kernels allowing the extra operation modes of the driver occurred. I think it may have been after the 6.5 kernels.
Note the underscore below. It should be:
$ cat /sys/devices/system/cpu/amd_pstate/status
Thanks for answers, but at the end fault was mine. Pstate cannot be loaded if in BIOS frequency is not set to auto . I set it to fixed x38, and that was whole problem.Since it is fixed and Cstate was disabled , frequency cannot be lowered, so driver cannot work.
Same apply to ECO mode, if freq is fixed and all cores running at 100% then will power usage be as usual, not fixed by ECO mode.
That’s correct. When CPU clock is fixed, there is no such need of managing the frequency of the CPU clock.
Modern processors use dynamic CPU clock frequencies. The frequency is managed by the CPU firmware and assisted by OS power management subsystem. AMD pstate driver is part of OSPM.
Zen2 and newer processors bring it to the next level which is beyond human perception.
Same apply to ECO mode, if freq is fixed and all cores running at 100% then will power usage be as usual, not fixed by ECO mode.
Eco-mode should not fix the frequency, at least not on my ASRock X570 Pro4 board. It should only limit the power targets, so the CPU does not draw more than 65W or 87W (depending on the CPU) at a given time. If Eco-mode is fixing the frequency to a specific number, then that is a fault of the board, and definitely not good.
I have the P-State driver working with Proxmox 8 and Eco-mode. I’m running the ASRock board w/ a R9 3900X, which should not be that much different than a 5900X.
And reason for trying ECO mode was few tests that show 10% drop in performance but huge drop in power consumption. I dont know how it was measured, but when you load mprime , put it on 100% CPU cannot lost 10% of performance and 30-40% of used power. Something must be incorrect 
In the end P=U*I^2 , so if you need full potential of CPU you must feed the beast
Was searching something totally unrelated the other day but ran into this LinuxCon video by the original author on amd pstate driver.
So the writing has been hanging on the wall for close to a year by now. “Preferred core” was on the roadmap. And drum roll the next new feature in AMD pstate after that will be “fast CPPC”
No idea at all about “Fast CPPC.” Seems only Zen 3 is explicitly mentioned in Linux kernel with support.
It may be that eco mode hits a more efficient voltage-frequency curve in this test. <10% loss of performance for >40% reduction in power consumption is around what I get from a mild undervolt and clockspeed cap on my 6700xt, and I’ve seen suggestions online that it’s similar with Zen3/4 CPUs.
For numbers; at stock, it bounces around 2550~2650mhz at 230w. After undervolt and capping the clockspeed to 2500mhz, it usually sits at cap at 90~120w depending on the game. Set power target to 120w, and it rarely dips below 2500mhz in-game.
AMD’s consumer parts have a very inefficient voltage-frequency target to reach peak performance, and can end up drawing much more power to get the last tiny bit of performance left out of the chip. It’s just the strategy they employ to stay ahead in benchmarks, and it makes sense with the product they have and the market they’re targeting.
For more efficient V-F parts, in the first place, they wouldn’t be using chiplets to serve that market since monolithic parts still win out in power efficiency.
