News: 0001500479

  ARM Give a man a fire and he's warm for a day, but set fire to him and he's warm for the rest of his life (Terry Pratchett, Jingo)

Linux 6.13 To Default To AMD P-State Driver For EPYC 9005 CPUs

([AMD] 5 Hours Ago AMD P-State On EPYC)


It was just earlier this week that [1]AMD posted Linux patches to switch EPYC over to using the AMD P-State driver rather than the long-used generic ACPI CPUFreq driver. This should lead to better power efficiency out-of-the-box and is a change being made just for EPYC 9005 "Turin" CPUs and future server processors. Already it's looking like this change will be introduced for the upcoming Linux 6.13 merge window.

On Monday the patches were posted so that the AMD EPYC 9005 series processors join the AMD Ryzen (Zen 2 and newer) processors in defaulting to the amd_pstate CPU frequency scaling driver rather than ACPI CPUFreq. For new 5th Gen AMD EPYC processors this should mean even better out-of-the-box power efficiency compared to the ACPI CPUFreq default. Existing AMD EPYC server customers can already switch over to AMD P-State assuming they have ACPI CPPC platform support but only now is AMD comfortable enough making this default change for their very newest server CPUs.

[2]

On Tuesday a pull request was submitted with the latest AMD P-State content for queuing into the Linux power management system's "-next" branch ahead of Linux 6.13. AMD Linux engineer Mario Limonciello wrote on that [3]pull request :

"Update the amd-pstate driver to set the initial scaling frequency policy lower bound to be lowest non-linear frequency. This will have a slight power consumption impact but should lead to increased efficiency.

Also amd-pstate is enabled by default on servers starting with newer AMD Epyc processors.

Add various code cleanups to rename functions and remove redundant calls."

Great seeing no time wasted there in getting this EPYC support by default queued up for amd-pstate so that it will make it into Linux 6.13. The Linux 6.13 merge window will be opening up during the back half of November while the stable kernel won't be launched until February.

I'm still working on some 5th Gen AMD EPYC AMD P-State vs. ACPI CPUFreq benchmarks and should have the numbers published in the coming days for performance and power efficiency.



[1] https://www.phoronix.com/news/AMD-P-State-EPYC-Linux-Patches

[2] https://www.phoronix.com/image-viewer.php?id=2024&image=amd_epyc_pstate_lrg

[3] https://lore.kernel.org/linux-pm/19b70e8a-7a11-46f6-ab9e-6dfaf315ef95@amd.com/


phoronix

On the other hand, the TCP camp also has a phrase for OSI people.
There are lots of phrases. My favorite is `nitwit' -- and the rationale
is the Internet philosophy has always been you have extremely bright,
non-partisan researchers look at a topic, do world-class research, do
several competing implementations, have a bake-off, determine what works
best, write it down and make that the standard.
The OSI view is entirely opposite. You take written contributions
from a much larger community, you put the contributions in a room of
committee people with, quite honestly, vast political differences and all
with their own political axes to grind, and four years later you get
something out, usually without it ever having been implemented once.
So the Internet perspective is implement it, make it work well,
then write it down, whereas the OSI perspective is to agree on it, write
it down, circulate it a lot and now we'll see if anyone can implement it
after it's an international standard and every vendor in the world is
committed to it. One of those processes is backwards, and I don't think
it takes a Lucasian professor of physics at Oxford to figure out which.
-- Marshall Rose, "The Pied Piper of OSI"