Eventually "Schedutil" Could Replace Linux's Existing CPU Scaling Governors
Following the brief tests of the new AMD CPUFreq CPPC solution, which isn't mainlined, a Phoronix reader pointed out a recent kernel mailing list discussion that went under our radar.
Upstream kernel developer Peter Zijlstra was critiquing several points of the proposed AMD CPPC code that AMD developers have been working on for Collaborative Processor Performance Control support with their new Zen 2 processors. Zijlstra rejected various elements of the AMD code proposal, including the calling it a "huge mistake" for exposing a lot of the data to user-space due to complicating future kernel efforts. He also rejected the idea of AMD creating a Linux user-space tool for generating CPPC profiles for target user workloads.
What's perhaps most interesting is the possible future of the CPU frequency scaling kernel code. Peter outlined his vision on the LKML where Schedutil could perhaps become the only scaling governor in the kernel.
We're trying to move all cpufreq into the scheduler and have only a single governor, namely schedutil -- yes, we're still stuck with legacy, and we're still working on performance parity in some cases, but I really hope to get rid of all other cpufreq governors eventually.So it's looking like the current AMD CPPC code likely won't make it mainline, but could benefit from generic ACPI CPPC code already within the kernel with some adaptations. And the future is certainly interesting if all of this work can eventually come together nicely. But given our recent Schedutil benchmarks compared to other governors, there's still more performance issues to first be addressed.
And if you look at schedutil (schedutil_cpu_util in specific) then you'll see it is already prepared for CPPC and currently only held back by the generic cpufreq interface.
It currently only sets desired freq, it has information for min/guaranteed, and once we get thermal integrated we might have
sensible data for max freq too.