News: 0001499756

  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)

AMD Posts Linux Patches For EPYC To Further Enhance Performance-Per-Watt By Default

([AMD] 3 Hours Ago AMD P-State For EPYC)


Making for an exciting Monday morning, AMD Linux engineers have kicked off the new week with a patch series introducing an exciting and long-awaited change: using the AMD P-State CPU frequency scaling driver by default for EPYC server platforms moving forward rather than the ACPI CPUFreq driver.

Since Zen 2 Ryzen and EPYC CPUs has been support for ACPI CPPC (Collaborative Processor Performance Control) for allowing greater control over managing the performance/power state of AMD CPU cores. But it wasn't until 2021 that the [1]AMD P-State driver for Linux came together for making use of ACPI CPPC for greater CPU frequency controls / power management compared to generic ACPI CPUFreq Linux driver. With [2]Linux 6.5 it became the default for modern Ryzen CPUs of using AMD P-State on supported systems but the AMD EPYC server processors have kept to using the ACPI CPUFreq driver by default... That is finally now changing. (Sans the exception of [3]EPYC 4004 having been on AMD P-State already due to being derived from the Ryzen parts.)

On any recent kernel the AMD P-State driver has typically worked quite well on Zen 2 / 3 / 4 / 5 hardware. There's been some exceptions with quirky motherboards like some Threadripper Zen 2 motherboards needing workarounds and such, but especially for Zen 4 and now Zen 5 the AMD P-State Linux driver has been working out great with Ryzen as I've shown in many benchmarks for power and performance.

Hitting the Linux kernel mailing list this Monday morning are two patches for beginning to default to using AMD P-State for EPYC platforms. But for now at least this default usage is being limited to Family 1Ah (EPYC 9005 series) and future platforms. Earlier AMD EPYC servers are sticking to ACPI CPUFreq for now at least pending additional testing or AMD feeling comfortable to make the change without risking existing AMD server customers.

In addition to the change to make amd_pstate default to EPYC 9005 (Family 1Ah), the other patch is for preventing frequency throttling on power-limited systems with AMD P-State active mode while using the performance governor.

The patch making the default change to AMD P-State for EPYC notes:

"Currently the default cpufreq driver for all the AMD EPYC servers is acpi-cpufreq. Going forward, switch to amd-pstate as the default driver on the AMD EPYC server platforms with CPU family 0x1A or higher. The default mode will be active mode.

Testing shows that amd-pstate with active mode and performance governor provides comparable or better performance per-watt against acpi-cpufreq + performance governor.

Likewise, amd-pstate with active mode and powersave governor with the energy_performance_preference=power (EPP=255) provides comparable or better performance per-watt against acpi-cpufreq + schedutil governor for a wide range of workloads.

Users can still revert to using acpi-cpufreq driver on these platforms with the "amd_pstate=disable" kernel commandline parameter."

See [4]this patch series for the proposed changes. I'll be running some performance and perf-per-Watt benchmarks on my side for EPYC Turin (and likely EPYC Genoa / Bergamo for reference and curiosity) with ACPI CPUFreq vs. AMD P-State shortly. Very excited to see this change materialize for switching to AMD P-State by default for EPYC moving forward. Hopefully the review process will go smoothly and we could potentially see these patches land for the Linux v6.13 cycle.



[1] https://www.phoronix.com/search/amd+p-state

[2] https://www.phoronix.com/review/linux65-ryzen-7950x

[3] https://www.phoronix.com/search/EPYC+4004

[4] https://lore.kernel.org/linux-pm/20241021101836.9047-1-gautham.shenoy@amd.com/



DesktopLinux

heavy, adj.:
Seduced by the chocolate side of the force.