AMD Posts P-State Linux Patches For New "Guided Autonomous Mode"

[phoronix]

Phoronix: AMD Posts P-State Linux Patches For New "Guided Autonomous Mode"

With the AMD P-State CPU frequency scaling driver that has come together over the past year and improved upon there has been the Energy Performance Preference "EPP" mode being worked on recently to further improve the performance/power characteristics of Ryzen and EPYC processors on Linux. A new patch series today implements a third mode for the AMD P-State driver...

https://www.phoronix.com/news/AMD-P-State-Guided-Auto

[Mitch]

I feel silly asking this, but I don't want to wait on these changes for 6 months. Is there a kernel out there that ports these things in like xamnod?
I'm on Fedora and if there's an easy way to put these into my own kernel, I'd be happy to use a guide as an alternative.

[V1tol]

I am using this repo (https://github.com/Frogging-Family/linux-tkg/) to build my own kernel for Arch and Fedora seems to have experimental support. I love it for simplicity - you can just throw a bunch of custom patches in a folder and they will be applied automatically. Not mentioning customization config with patches applied by default. That's what I've been using to have MGLRU for almost a year now.

[deets]

I feel silly asking this, but I don't want to wait on these changes for 6 months. Is there a kernel out there that ports these things in like xamnod?
I'm on Fedora and if there's an easy way to put these into my own kernel, I'd be happy to use a guide as an alternative.

I am using this repo (https://github.com/Frogging-Family/linux-tkg/) to build my own kernel for Arch and Fedora seems to have experimental support. I love it for simplicity - you can just throw a bunch of custom patches in a folder and they will be applied automatically. Not mentioning customization config with patches applied by default. That's what I've been using to have MGLRU for almost a year now.

I've used the TKG patchset for a while, but I've recently found an alternative that I much prefer:

https://github.com/CachyOS/kernel-patches

It has pretty much all the patches from TKG, and more.

Within the last 15 minutes, they have added p-state patches from this OP (this is the reason I created my account here, as I found the timing to be amusing).

I'm not sure how it would work for something like Fedora. Personally, I just take all the patches and apply them using /etc/portage/patches with Gentoo, but I believe there are helpers within Cachy's repo for other OS (I would assume setting it up for Arch would be pretty easy, for example).

[kiffmet]

The CachyOS kernel comes to mind. It's offered in many different flavours. All the patches that form the different versions can be found here.

[ATLief]

Even though this driver is open source, I don’t like the gradual movement of functionality from cpu-agnostic features to specific drivers.

It also seems weird that a driver with the original purpose of enacting governor choices would have anything to do with making its own governor choices.

[intelfx]

Even though this driver is open source, I don’t like the gradual movement of functionality from cpu-agnostic features to specific drivers.

It also seems weird that a driver with the original purpose of enacting governor choices would have anything to do with making its own governor choices.

Unfortunately the governor/driver separation appears to do more harm than good. Either that, or nobody seems interested in developing CPU-agnostic governors to match the decision-making quality of proprietary firmware-driven algorithms.

Unless somebody puts in the required (probably massive) amounts of R&D work, nothing is probably going to change.

[Linuxxx]

Even though this driver is open source, I don’t like the gradual movement of functionality from cpu-agnostic features to specific drivers.

It also seems weird that a driver with the original purpose of enacting governor choices would have anything to do with making its own governor choices.

That's because "schedutil" utterly failed to live up to the hype.

Thus, even upstream recognizes this by suspending work on further improving that broken governor and going the hardware-specific route.

Anyway, using the performance governor will continue to be the best choice for most desktop users, simply because it guarantees the lowest latencies.

[agd5f]

Unfortunately the governor/driver separation appears to do more harm than good. Either that, or nobody seems interested in developing CPU-agnostic governors to match the decision-making quality of proprietary firmware-driven algorithms.

Unless somebody puts in the required (probably massive) amounts of R&D work, nothing is probably going to change.

I think there are two problems:

1. Governors are cpu-freq driver agnostic. For a governor to work well, I think it needs to be tuned to the underlying implementation. CPPC is designed around an abstract performance target interface, but in order to be compatible with cpu-freq everything gets converted into frequencies.
2. HW/FW is almost always in a better position than the CPU when it comes to the clocking decisions. It has direct access to perf counters, thermals, power draw, etc. The kernel could get all of that data, but the latency would be higher and it would eat up a core on the system.

[ATLief]

2. HW/FW is almost always in a better position than the CPU when it comes to the clocking decisions. It has direct access to perf counters, thermals, power draw, etc. The kernel could get all of that data, but the latency would be higher and it would eat up a core on the system.

I think it has access to different information, not necessarily more; I don't think cpus have any concept of "niceness" or time-sensitive vs non-time-sensitive actions (like checking for new email vs foreground user interface updates). I'm not sure if it even knows which collection of instructions belong to the same process. Maybe you could forward that info to the cpu, but in that case you're probably better off doing that in kernel/user-space.