The next major Linux kernel release, version 7.3, will let users and system tools tune AMD’s Dynamic Energy Performance Preference (EPP) on a per-core basis, rather than applying a single power hint across the entire processor. The change, currently queued for the upcoming kernel cycle and reported by Phoronix on July 31, refines a feature that first arrived in Linux 7.1 and is especially relevant for Ryzen-powered laptops, gaming handhelds, and compact PCs where workloads rarely spread evenly across every CPU core.
A smarter power policy for uneven workloads
AMD P-State is the modern frequency-scaling driver for supported Ryzen processors under Linux. Instead of relying on older ACPI interfaces, it uses AMD’s Collaborative Processor Performance Control (CPPC) to send performance hints more quickly and with finer granularity. The Energy Performance Preference (EPP) is one of those hints — not a hard clock-speed cap, but a suggestion that tells the hardware whether to favor immediate performance or energy efficiency when selecting an operating point within the limits the OS sets.
Linux 7.1 introduced Dynamic EPP to the AMD P-State driver as a mobile-friendly feature. When enabled, the kernel can automatically adjust the EPP hint based on whether the machine is on AC power or battery, and in response to platform profile changes (e.g., “balanced” vs. “power saver”). Plug in a laptop and the driver leans toward performance; unplug and it shifts conservatively. The kernel documentation, however, notes a clear trade-off: with Dynamic EPP active, direct writes to the normal energy_performance_preference control are blocked to prevent two controllers — the automatic kernel policy and a user-space daemon — from fighting over the same setting. That made Dynamic EPP an all-or-nothing choice at the system level.
Linux 7.3 changes that. The new code, as reported by Phoronix, makes Dynamic EPP tunable at per-core granularity. A power-management stack could now allow automatic EPP transitions on background-oriented cores while preserving a manually selected, performance-oriented preference for cores pinned to latency-sensitive work — a game’s render thread, a virtual machine, or a compilation job. Conversely, an administrator could keep the automatic behaviour broadly in place but exempt a core assigned to a critical service.
Gamers and laptop owners stand to benefit most
The practical impact varies by user profile. For everyday Linux laptop owners, the change will probably arrive quietly via distribution updates — a new kernel that simply enables smarter power distribution without any manual tinkering. The real upside is that your system might run cooler, last longer on battery, and still feel snappy when a single core works hard, because the driver is no longer forced to send the same “save power” hint to every core when you unplug the charger.
Steam Deck owners and those running Bazzite, ChimeraOS, or other gaming-focused Linux builds on handhelds like the ASUS ROG Ally and Lenovo Legion Go stand to gain even more. These devices share a constrained power and thermal budget between the CPU and GPU. A game’s main thread often wakes, runs intensely, sleeps while waiting for a frame boundary, then needs to resume quickly. The per-core capability lets the system keep a performance-friendly EPP on the core running that thread while the surrounding cores idle with more energy-conscious hints — concentrating the battery budget where it matters. Phoronix’s separate coverage of a proposed “epp_boost” mechanism (not yet merged into 7.3) demonstrated a 31.8% improvement in 1%-low frame rates in Civilization VI on a Steam Deck when recently busy cores received a temporary EPP boost. Though distinct from the per-core Dynamic EPP feature, the two ideas point toward the same goal: avoiding crude, system-wide power decisions that hurt frame-time consistency.
IT professionals managing Ryzen-based Linux workstations or servers get a different kind of relief. A global Dynamic EPP switch forced a choice between automatic laptop-friendly behaviour and manual performance tuning. Per-core tuning breaks that lockstep. A developer’s build server could keep automatic policies on most cores while pinning a specific core to a lower EPP value for a latency-sensitive service, without disabling the entire automatic mechanism. The feature also reduces friction between the kernel policy and user-space power frameworks like power-profiles-daemon. Instead of an all-or-nothing fight over who gets to write the EPP value, tools can divide ownership by core.
The road from system-wide hints to per-core control
AMD P-State has evolved rapidly. After being mainlined and refined over several kernel cycles, the Linux 7.1 release made Dynamic EPP the default for mobile Ryzen systems that supported CPPC v2 or newer. The kernel documentation for Linux 7.1 explicitly stated that writing to energy_performance_preference is “ignored when the amd-pstate driver is using Dynamic EPP because this write operation does not affect the dynamic behaviour.” That sentence now needs a footnote for Linux 7.3: “unless you’ve explicitly exempted that core.”
The context matters. On July 28, just days before the per-core EPP report, Phoronix previewed a separate AMD P-State patchset — epp_boost — that would temporarily apply a high-performance EPP value to individual cores that have been recently busy, then decay back. That work is still under discussion and not part of Linux 7.3, but it illustrates the direction: power management is no longer a choice between boosting everything and saving everywhere. The kernel is building the infrastructure to treat idle cores, background cores, and bursty cores differently.
For most users, the driver’s active mode is where they’ll see these changes. AMD P-State supports several modes — active, passive, and guided — and features depend on firmware support and kernel configuration. Checking which driver is in use remains simple: cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_driver will show either amd-pstate or the older acpi-cpufreq. But seeing amd-pstate does not guarantee per-core Dynamic EPP; you’ll also need a Ryzen system with the appropriate CPPC support, a UEFI/BIOS that cooperates, and a kernel at 7.3 or later.
Should you start tweaking your cores right now?
No — at least not yet. Linux 7.3 is still an upcoming kernel release, and the per-core controls will only appear in the sysfs interface once distributions begin shipping it. When they do, the exact knobs will likely live under /sys/devices/system/cpu/cpu*/cpufreq/energy_performance_preference and a new per-core Dynamic EPP toggle. But even then, resist the urge to randomly punch in values. Poor affinity decisions can concentrate heat, worsen boost behaviour, or draw more power for no real gain. On a conventional desktop PC that stays plugged in, the default system-wide policy is probably fine.
For those who do need fine-grained control, a few steps will be essential: first, identify which cores carry your performance-critical threads (tools like top, htop, or taskset can help). Second, test in small increments — set a static EPP of, say, 0 (full performance) on one core while leaving others on auto, then measure whether your frame rate, compile time, or service latency actually improves. Third, remember that Dynamic EPP is just a hint — thermals, firmware power limits, and the scheduler still have the final say.
Distribution maintainers and handheld OS developers will shape the real-world experience. They can build user-facing controls that let gamers select “per-core aware” as a power profile, or that let IT administrators deploy a tuned policy without exposing raw sysfs paths. The kernel provides the building block; the usability story depends on what sits above it.
What comes after Linux 7.3
The per-core Dynamic EPP change will land in the 7.3 merge window, likely followed by several months of stabilization and distribution testing. Fedora, Ubuntu, and Arch Linux tracking the mainline kernel will pick it up on different schedules, while Chrome OS and SteamOS may integrate it on their own timelines. The immediate question is whether the additional granularity leads to measurable battery-life or frame-time improvements in popular workloads, or whether it remains an expert-only tuning file.
Longer term, watch for the proposed epp_boost patches to mature. If merged, they could complement per-core Dynamic EPP by automatically giving busy cores a temporary performance nudge, while the per-core policy controls which cores are allowed to receive automatic AC/DC switching in the first place. Together, they would represent a meaningful shift away from a one-size-fits-all power model — and toward a system that truly sees the CPU as a collection of unevenly loaded cores, not a monolithic block.