I just redid my Geekbench 6.1 benchmarks for comparisons between my previous runs on 6.5-rc2 and my current 6.2 kernel.
With the same exact settings, the ST numbers are within testing tolerances but I lost over 2000 points in the MT part of the benchmark for having to run under the 6.2 kernel.
This was on my 7950X host. I still have my Epyc 7713 host running on the 6.5-rc2 kernel and noticed a big speedup in processing for that host compared to the previous kernel I had on it.
Linux 6.4+ has amd_pstate driver enabled by default. Linux 6.5 has “guided” mode of amd_pstate merged. Though “guided” mode is user opt-in feature, meaning you’ve to enable it through Kernel command line.
Personally I use “performance” cpufreq governor which works best and I don’t see a power consumption difference between “performance” and “schedutil” for my little box.
So if you have to have “schedutil” paired with amd_pstate driver, you will see “significantly” better performance. Perhaps that’s what you’ve observed on 7950X running 6.5-rc2.
Well I found out how to install the gcc-13 and g++ -13 compilers and now am back on the 6.5-rc kernels. So regained my GB6.1 benchmark number for ST and MT.
But I have to manually call the amd_pstate driver in the kernel command line to get the amd_pstate driver to install. Opposite of what the Phoronix article said the 6.5 kernels would install by default on the consumer boards. I know I have to call it explicitly for the server boards.
amd_pstate has three modes of operations: passive (6.3+), active (6.3+) and guided (6.4+)
Linux 6.5+ has enabled ‘amd_pstate=active’ by default. Guided mode is mainlined in 6.4 but remains a user opt-in feature.
Doesn’t matter what mode you want. It only installs the standard acpi-cpufreq driver IF you DON’T manually invoke the amd_pstate=xxxx driver in kernel command line.
It’s supposed to be amd_pstate=active in the 6.5 kernels for Ryzen Zen 4 cpus now according to the Phoronix articles.
Still have to manually invoke amd_pstate driver for servers boards and cpus though.
I have a 7950X on a ASUS Crosshair X670E board that doesn’t install the amd_pstate driver by default. Should’nt have to call it manually.
Don’t know why you are referencing Kconfig. I am not compiling my own kernels.
I am just using what the Kernel Mainline PPA is providing.
It seems they are not setting a default mode or something.
I should make a post at Phoronix in that article disputing their assertion.
I’m only able to run GB6 in VM. Hence, was not able to produce any performance difference (as expected).
Your result is very interesting. It seems to show “Preferred Core” enhancement outperforms by a tiny bit. If it can be consistently demonstrated, then great news.
I have one anecdotal evidence. My Prime95 tests above ambient temperature 30C often are at the brink of crash. With “Preferred Core” patch, these P95 tests seem to run fine above 30C ambient. Surprise. Hope I don’t speak too soon.
Running the 6.5-rc7 kernel now on the 7950X. Now defaults to amd_pstate_epp driver as default. No kernel command line edits necessary.
Good to hear. I had the impression you were trying to compile your custom kernel…
I’ve updated my Kernel from 6.4.8 to 6.4.11. Seems a bit of change that broke the compatibility of “Preferred Core” patch was also backported somehwere between .9 and .11. The vanilla “Preferred Core” patch will just compile fine without any further change.
“Preferred Core” patch is currently at V2 [0]. What’s new: not much functionally. It is turned on by default, no longer requiring Kernel command line. Changed status file name from “prefcore_state” to “prefcore”. Hence, to check enabled or not at run time, use this from V2 onwards:
$ cat /sys/devices/system/cpu/amd_pstate/prefcore
enabled
I’m running Arch Linux 6.4.11-arch2-1 with a 5900X and added amd_pstate=active to the kernel parameters. Nice! Thanks!
Same performance as before under heavy workload (compiling ungoogled-chromium) but picked up a couple more reduced clock/power states for when it’s just idling along web browsing/emailing/etc (which is most of the time).
Thanks for the input. I was wondering if prefcore is only really useful for a lightly loaded state. Probably does not help with a heavily loaded state like I run 24/7.
I am running the latest 6.5 kernels simply to pick up the available sensors from my motherboard. Only reason really.
Phoronix posted some benchmarks with a 7950x:
amd-pstate vs acpi-cpufreq…
EDIT:
Should have emphasised that the comparison in this Phoronix article is amd-pstate /w powersave governor VS. acpi-cpufreq /w schedutil governor.
It’s debatable if absolute performance comparison based on two different CPU governors make sense at all.
Also, people after absolute performance may be already running on ‘performance’ governor. Then the difference won’t be so profound as the Phoronix charts may have suggested.
Phoronix always tests “out-of-the-box” settings. So their test results represent what someone would experience without changing or tweaking default settings.
I agree, if both acpi-cpufreq and amd-pstate drivers were run with “performance” governor, the results would be exactly the same except possibly for the power efficiency tests. The amd_pstate driver allows much lower idle clocks than acpi-cpufreq driver.
Here is my take on amd-pstate.
One advantage is that it allows user space to have some finer control over how the Zen CPU firmware should perform. I forgot that’s “passive” or “active” mode, likely the latter. I think most people won’t bother with manual fine tune though.
Another advantage is the much improved performance on “schedutil” governor. It’s improved a lot when paired with amd-pstate vs. paired with acpi-cpufreq. Most distribution default to “schedutil” governor out-of-the-box.
My quick test showed “schedutil” with amd-pstate is almost as good as “performance” with amd-pstate. You’ll save <1W on idle with schedutil on a single CCD Zen processors. I’m curious how much people would save on multi-CCD Zen processors.
The last advantage is the “preferred core” enhancement that’s coming to Linux 6.6 or 6.7. I think this props up Zen experience on Linux to exceed that on Windows if not just on par.
Ok, another possible advantage is lower power consumption on laptops but I haven’t paid much attention on this aspect.
Given acpi-cpufreq and amd-pstate, it’s no brainer to switch to amd-pstate once available on your distribution.
I’ve just set my epp hint to performance and it sticks through reboots.
Since I run 100% flat out all the time my clocks are always limited by power budget and temps anyway.
Not going to see maximum clocks out of any core while my normal workload is running.
Interesting. What do you run on your machines?
I think “preferred core” enhancement actually will benefit your case. That’s assume you run your jobs on bare metal. The scheduler will be able to pick the best core for the next runnable task given the current thermal and power conditions.
AMD roughly calls it “dynamic ranking of preferred cores”.
I run BOINC on all hosts. Mix of different science projects. Universe@home for the most part on all the cpus along with enough cpu core support to feed 2-3 RTX 3080’s in each host for the the gpu projects, primarily Einstein@home.
PSA: If you have defined an optimized curve for your Ryzen processor and have only tested it in Linux, you might be in for a surprise after enabling amd_pstate. I have had two systems now that were ostensibly stable start throwing MCEs with amd_pstate, requiring me to go with a less aggressive curve offset across the board just to get it stable again. My assumption is that amd_pstate is so good at idling cores that it has exposed some soft spots on the low end of the V-F curve.
I ended up flashing the latest AGESA 120A that fixes the EDC bug and redoing curve optimizer from scratch on both systems.