AMD P-State CPU Frequency Control Driver Revised A 6th Time

[phoronix]

Phoronix: AMD P-State CPU Frequency Control Driver Revises A 6th Time

Making a Sunday debut are the amd-pstate v6 patches as the latest iteration of this work for improving the AMD CPU frequency control behavior on Linux for more optimized power efficiency with modern Zen 2 / Zen 3 series (and future) processors...

https://www.phoronix.com/scan.php?page=news_item&px=amd-pstate-v6

[perpetually high]

Excellent. Gonna give these a whirl soon on my 5800X.

I've been using the acpi-cpufreq schedutil with good success so far, excited to see what improvements this new driver brings.

Below was while compiling the kernel. Single-core peaks at 4.925 GHz and multi-core at 4.65 GHz. Not too shabby. 140-150W power usage.

[Random_Jerk]

Excellent. Gonna give these a whirl soon on my 5800X.

I've been using the acpi-cpufreq schedutil with good success so far, excited to see what improvements this new driver brings.

Below was while compiling the kernel. Single-core peaks at 4.925 GHz and multi-core at 4.65 GHz. Not too shabby. 140-150W power usage.

Can you please elaborate on how to install this driver ?

[perpetually high]

Random_Jerk it's pretty involved actually, but doable.

1) Requires unloading the k10temp kernel module: $ sudo modprobe -r k10temp (you can then add it to the blacklist once you verify everything works)
2) Then you have to build the zenpower3 kernel module and load it: $ sudo modprobe zenpower
3) You can verify what modules are loaded with: $ lsmod | grep -E 'k10temp|zenpower'
4) Build zenmonitor3 and then run ./zenmonitor

Let me know if you get stuck along the way.

edit: Interesting, I had actually missed a step along the way when setting things up.

Once you verify everything works. You can do the following:

5) sudo ./zenmonitor (won't have GTK theme)

or

5) $ sudo setcap cap_sys_rawio,cap_dac_read_search+ep
6) ./zenmonitor
7) Optionally, you can create an alias to it so it's not attached to a terminal: $ ./zenmonitor </dev/null &>/dev/null &

So now if you run it, it'll give you the full readings below:

[perpetually high]

fyi: sirlucjan hosts these patches (not the newest ones yet in this article, but the previous version).

See here if interested: https://github.com/sirlucjan/kernel-...patches-v4-sep

[cytomax55]

Does this help with performance or only helps optimize power usage

[perpetually high]

Alright beautiful people, we're up and running. Requires amd_pstate.enable=1 in GRUB.

Scaling Driver: amd-pstate schedutil (Boost: Enabled)

When I ran dmesg, it showed this helpful output:

[ 3.539060] amd_pstate: This processor supports shared memory solution, you can enable it with amd_pstate.shared_mem=1

so in GRUB I've added:

amd_pstate.enable=1 amd_pstate.shared_mem=1

dmesg now shows:

[ 3.810360] powernow_k8: WTF driver: amd-pstate

We're rockin and a rollin.

zenmonitor3 still works with this new governor, but not as much info as of right now:



edit: Some quick initial benchmarks, will wait for Michael's full suite:

pts/osbench

Geometric Mean:

Ubuntu's 5.13.0-23-generic .......................... 6.248
xanmod's 5.15.10 .................................... 6.711
p h's 5.16-rc5, amd_pstate schedutil v6 8.044
p h's 5.16-rc5 ......................... 8.129
p h's 5.15.10 .......................... 8.139

So a smidgen slower, but I think I'm gonna stick with it for now (with that shared mem support) and see if I can notice a difference on day to day.

[CochainComplex]

amd_pstate.enable=1 amd_pstate.shared_mem=1

Thanks for sharing your investigation. Works great on my 3600XT. But I think passing amd_pstate.shared_mem=1 is enough at least for me it was inough to initate the amd_pstate driver.

[Linuxxx]

Alright beautiful people, we're up and running. Requires amd_pstate.enable=1 in GRUB.

Scaling Driver: amd-pstate schedutil (Boost: Enabled)

When I ran dmesg, it showed this helpful output:

[ 3.539060] amd_pstate: This processor supports shared memory solution, you can enable it with amd_pstate.shared_mem=1

so in GRUB I've added:

amd_pstate.enable=1 amd_pstate.shared_mem=1

dmesg now shows:

[ 3.810360] powernow_k8: WTF driver: amd-pstate

We're rockin and a rollin.

zenmonitor3 still works with this new governor, but not as much info as of right now:



edit: Some quick initial benchmarks, will wait for Michael's full suite:

pts/osbench

Geometric Mean:

Ubuntu's 5.13.0-23-generic .......................... 6.248
xanmod's 5.15.10 .................................... 6.711
p h's 5.16-rc5, amd_pstate schedutil v6 8.044
p h's 5.16-rc5 ......................... 8.129
p h's 5.15.10 .......................... 8.139

So a smidgen slower, but I think I'm gonna stick with it for now (with that shared mem support) and see if I can notice a difference on day to day.

Could You also throw the performance governor into the mix?

Since your 5800X is a single CCX one, I believe the performance governor shouldn't trigger the unfortunate side-effect of drastically increased temperatures as seen on multi-CCX Ryzens. [Infinity Fabric upclocking?]

(Which also makes me hopeful that the Steam Deck could be run with the performance governor instead of schedutil, at least when docked.)

Thanks!

[kiffmet]

I am currently testing the old "v4" (this should be the equivalent to v5 on the mailing list, as lucjan uses his own versioning scheme in his repo) on my 3900X in combination with schedutil and the ProjectC/PDS scheduler. On the first glance: My idle clockspeeds are lower (533Mhz - never seen that value before), and so is the total CPU core idle wattage (maybe core parking works better now?).

My single core turbo is getting reached much much more quickly and also a tad more often. My best core reached 4.625GHz while writing this post (which occured maybe once a month before) and core 1,2,6-11 are seeing a +25Mhz higher speed in background tasks aswell (which they never did in over 1.5yrs of usage). All-core clockspeeds seem ever so slightly higher (avg +25Mhz, +75Mhz in bursts), but that might be due to lower ambient temps… It definitely looks like frequency selection is behaving better than on Windows now



Possible side effects: My CPU reports receiving up to 1.519V SVI2-TFN now (X570 Aorus Pro r1.0, F34, PBO disabled, "Auto" multiplier, voltages and LLC);
Might be unrelated, a measurement error caused by zenmonitor (or its out-of-trree driver) being used alongside amd_pstate or maybe something like register polling happening more frequently now (after all, CPPC should allow changing the frequency within ~1ms instead of ~30ms). I'm pretty sure that the moving average stays well below 1.5 and since it's only ~1% deviation and doesn't happen under full load, it's probably not a reason to worry.

I'll post an update once I know how this affects frametimes in games and a timed kernel compilation.