Linux 7.3 is set to give AMD laptop and handheld owners a more precise way to manage power behavior: the kernel’s AMD P-State driver will allow its Dynamic Energy Performance Preference, or Dynamic EPP, behavior to be tuned at per-CPU-core granularity rather than as a single system-wide choice. The change matters because modern Ryzen systems rarely have one uniform workload. A game’s busy render thread, a browser tab, background synchronization and idle cores should not necessarily receive the same performance-versus-battery-life instruction.
Phoronix reported the incoming Linux 7.3 work on July 31, following the earlier arrival of Dynamic EPP in Linux 7.1. For Linux users on Ryzen notebooks, Steam Deck-class handhelds, and compact PCs, the practical payoff is more control over which cores are allowed to follow the kernel’s automatic AC-versus-battery EPP policy and which retain an administrator or power-management tool’s chosen behavior.
That is a relatively small driver-interface change, but it addresses a real limitation in how Linux has handled AMD’s more granular CPU power controls.
AMD P-State is Linux’s modern CPU frequency-scaling driver for supported AMD processors. Rather than relying solely on the older ACPI CPU frequency model, it uses AMD’s Collaborative Processor Performance Control, or CPPC, interfaces to communicate performance preferences to the processor more quickly and with finer resolution.
EPP is the Energy Performance Preference portion of that mechanism. It is not a hard clock-speed setting. Instead, it is a hint that tells the platform whether to favor immediate performance or energy efficiency when choosing an operating point inside the limits the operating system has established. Lower EPP values lean harder toward performance; higher values favor power savings.
Linux 7.1 added Dynamic EPP to AMD P-State as a convenience feature for mobile hardware. When enabled, the driver can change the selected preference based on whether the machine is on AC power or battery, while also responding to platform-profile changes. In a conventional laptop scenario, that is sensible: a system plugged into wall power can choose a more performance-oriented preference, while the same machine on battery can take a more conservative posture.
The Linux kernel documentation is explicit about the trade-off. With Dynamic EPP active, direct writes to the normal
That broad switch is the part Linux 7.3 is preparing to refine.
Dynamic EPP’s original system-level control was well suited to the simple question of whether a laptop is plugged in. It was less well suited to the question of whether every core should have its EPP automatically changed in response to that power-source event.
Phoronix’s reporting indicates Linux 7.3 will make Dynamic EPP tunable at per-core granularity. That creates room for a more practical division of responsibility. A power-management stack could permit automatic EPP transitions on background-oriented cores while preserving a manually selected preference for cores assigned to a latency-sensitive workload. Conversely, an administrator could keep automatic behavior in place broadly but exempt a core used by a pinned service or a specialized application.
The exact user-space integration will matter as much as the kernel capability. Most desktop users do not directly manipulate
For the moment, this is principally a new building block for distribution maintainers, handheld OS developers, performance-tool authors, and users who already understand CPU affinity and P-State tuning.
That work is not the same feature as Dynamic EPP’s AC/DC policy switching, and it should not be treated as already merged into Linux 7.3. But the two efforts point in the same direction: Linux power management is trying to avoid a crude choice between boosting every core and conserving power everywhere.
The proposed
Phoronix reported a 31.8% improvement in 1%-low frame rates in a Civilization VI test on Valve’s Steam Deck with that proposed per-core boost mechanism. That is a single benchmark on a single device, not a universal promise for Ryzen PCs or every game. Still, it demonstrates why granular policy is attractive on hardware where the CPU and GPU share a constrained power budget.
For Steam Deck, ASUS ROG Ally, Lenovo Legion Go, and similar systems running Linux-based gaming environments, spending the battery budget on the core that actually needs it is more valuable than issuing a blanket performance request to the entire CPU. The same logic applies to thin-and-light Ryzen laptops compiling code on one core while trying to remain quiet and cool in a meeting.
AMD P-State supports several modes with different degrees of operating-system and hardware autonomy. On compatible systems, the active EPP driver allows the platform to make operating-point decisions from the supplied hints. Linux also has policy limits and governor controls, while newer AMD P-State work has added features such as CPPC performance priorities and frequency floors for selected conditions.
Dynamic EPP sits above those mechanics as an automatic policy layer. Its job is to decide which energy/performance preference should be fed to the hardware under conditions such as changing from wall power to battery. Linux 7.3’s per-core tuning does not mean every Ryzen processor suddenly gains a new kind of boost behavior. It means the kernel can apply or withhold that automatic policy more selectively where the platform and driver support it.
Compatibility will remain dependent on the processor, BIOS or UEFI firmware, the active Linux driver mode, and the distribution’s kernel configuration. Users can check which CPU frequency driver is operating through the standard CPUFreq policy information, but they should not assume that seeing AMD P-State means every recent feature is enabled. Firmware support and the distinction between active, passive, and guided modes remain significant.
Consider a Ryzen-based Linux workstation running a latency-sensitive local service, a virtual machine host with CPU-pinned workloads, or a software-development machine where certain cores are deliberately reserved. A global Dynamic EPP switch forces the administrator to choose between automatic laptop-friendly behavior and manual control. Per-core tuning makes that choice less absolute.
It could also reduce friction between kernel policy and user-space power frameworks. Dynamic EPP previously protected itself by rejecting manual EPP writes when enabled. That remains the right general safeguard: uncontrolled competing writes create unpredictable behavior. But allowing the automatic feature to be scoped by core gives tools a clearer way to divide ownership instead of disabling Dynamic EPP across the entire system.
There is a caution here. More knobs do not automatically produce better battery life or faster systems. Poor affinity decisions can concentrate heat, worsen boost behavior, or consume more power for negligible gains. On conventional desktop PCs, the default policy may still be the best choice. Per-core tuning is most valuable where workloads are well understood and the platform has a genuine battery, thermal, or shared-power constraint.
The key question after merge will be whether desktop distributions and handheld-focused Linux projects turn the new granularity into coherent defaults rather than another expert-only tuning file. If they do, the benefit will not be a flashy new CPU mode. It will be a quieter, longer-lasting Ryzen system that still gives its busiest core the performance it needs when it needs it.
That is a relatively small driver-interface change, but it addresses a real limitation in how Linux has handled AMD’s more granular CPU power controls.
Dynamic EPP Was Useful, but Broad
AMD P-State is Linux’s modern CPU frequency-scaling driver for supported AMD processors. Rather than relying solely on the older ACPI CPU frequency model, it uses AMD’s Collaborative Processor Performance Control, or CPPC, interfaces to communicate performance preferences to the processor more quickly and with finer resolution.EPP is the Energy Performance Preference portion of that mechanism. It is not a hard clock-speed setting. Instead, it is a hint that tells the platform whether to favor immediate performance or energy efficiency when choosing an operating point inside the limits the operating system has established. Lower EPP values lean harder toward performance; higher values favor power savings.
Linux 7.1 added Dynamic EPP to AMD P-State as a convenience feature for mobile hardware. When enabled, the driver can change the selected preference based on whether the machine is on AC power or battery, while also responding to platform-profile changes. In a conventional laptop scenario, that is sensible: a system plugged into wall power can choose a more performance-oriented preference, while the same machine on battery can take a more conservative posture.
The Linux kernel documentation is explicit about the trade-off. With Dynamic EPP active, direct writes to the normal
energy_performance_preference control are blocked. That prevents two controllers—the automatic kernel policy and a user or daemon—fighting over the same setting. But it also makes the feature an all-or-nothing decision.That broad switch is the part Linux 7.3 is preparing to refine.
A Single Policy Does Not Fit Every Core
The per-core change is important because “the CPU” is an increasingly misleading unit of measurement. Even on a processor made of nominally identical cores, workloads are uneven. One core may be intermittently running a game’s main thread, an audio-processing thread, a compiler job, or a virtual machine vCPU. Several others may be largely idle. Treating their power preferences identically can either leave responsiveness on the table or spend more power than the workload warrants.Dynamic EPP’s original system-level control was well suited to the simple question of whether a laptop is plugged in. It was less well suited to the question of whether every core should have its EPP automatically changed in response to that power-source event.
Phoronix’s reporting indicates Linux 7.3 will make Dynamic EPP tunable at per-core granularity. That creates room for a more practical division of responsibility. A power-management stack could permit automatic EPP transitions on background-oriented cores while preserving a manually selected preference for cores assigned to a latency-sensitive workload. Conversely, an administrator could keep automatic behavior in place broadly but exempt a core used by a pinned service or a specialized application.
The exact user-space integration will matter as much as the kernel capability. Most desktop users do not directly manipulate
sysfs controls, and they should not have to. Distributions commonly expose profile choices through firmware tools, desktop power daemons, or utilities such as powerprofilesctl. Those projects will need to decide how, or whether, to surface a core-by-core policy in a way that is understandable and safe.For the moment, this is principally a new building block for distribution maintainers, handheld OS developers, performance-tool authors, and users who already understand CPU affinity and P-State tuning.
The Timing Favors Handheld Gaming and Mobile Linux
The change arrives as AMD P-State work is becoming more focused on workload-specific behavior rather than static “performance” or “powersave” modes. On July 28, Phoronix separately covered a proposed AMD P-State feature calledepp_boost, which would temporarily apply a performance-oriented EPP value to individual recently busy cores.That work is not the same feature as Dynamic EPP’s AC/DC policy switching, and it should not be treated as already merged into Linux 7.3. But the two efforts point in the same direction: Linux power management is trying to avoid a crude choice between boosting every core and conserving power everywhere.
The proposed
epp_boost work is aimed at an especially visible gaming problem. Many games have a main or render thread that works intensely, sleeps briefly while waiting for a frame boundary, GPU fence, or synchronization event, then needs to resume quickly. If the processor interprets those short waits as an opportunity to reduce performance too aggressively, the next burst can begin at a lower operating point. The result may be poorer frame-time consistency even when the average frame rate looks acceptable.Phoronix reported a 31.8% improvement in 1%-low frame rates in a Civilization VI test on Valve’s Steam Deck with that proposed per-core boost mechanism. That is a single benchmark on a single device, not a universal promise for Ryzen PCs or every game. Still, it demonstrates why granular policy is attractive on hardware where the CPU and GPU share a constrained power budget.
For Steam Deck, ASUS ROG Ally, Lenovo Legion Go, and similar systems running Linux-based gaming environments, spending the battery budget on the core that actually needs it is more valuable than issuing a blanket performance request to the entire CPU. The same logic applies to thin-and-light Ryzen laptops compiling code on one core while trying to remain quiet and cool in a meeting.
The Existing Controls Still Set the Boundaries
It is worth separating EPP from other AMD P-State controls, because the terminology can make the change seem larger than it is. EPP influences the hardware’s choice within an allowed range. It does not override thermal protection, firmware power limits, battery capacity, a configured maximum frequency, or the operating system scheduler.AMD P-State supports several modes with different degrees of operating-system and hardware autonomy. On compatible systems, the active EPP driver allows the platform to make operating-point decisions from the supplied hints. Linux also has policy limits and governor controls, while newer AMD P-State work has added features such as CPPC performance priorities and frequency floors for selected conditions.
Dynamic EPP sits above those mechanics as an automatic policy layer. Its job is to decide which energy/performance preference should be fed to the hardware under conditions such as changing from wall power to battery. Linux 7.3’s per-core tuning does not mean every Ryzen processor suddenly gains a new kind of boost behavior. It means the kernel can apply or withhold that automatic policy more selectively where the platform and driver support it.
Compatibility will remain dependent on the processor, BIOS or UEFI firmware, the active Linux driver mode, and the distribution’s kernel configuration. Users can check which CPU frequency driver is operating through the standard CPUFreq policy information, but they should not assume that seeing AMD P-State means every recent feature is enabled. Firmware support and the distinction between active, passive, and guided modes remain significant.
Administrators Gain an Escape Hatch From Policy Collisions
For IT professionals, the real value is not likely to be hand-tuning every core on an office fleet. It is avoiding unwanted interactions between automatic power policy and the systems that already manage performance for a particular job.Consider a Ryzen-based Linux workstation running a latency-sensitive local service, a virtual machine host with CPU-pinned workloads, or a software-development machine where certain cores are deliberately reserved. A global Dynamic EPP switch forces the administrator to choose between automatic laptop-friendly behavior and manual control. Per-core tuning makes that choice less absolute.
It could also reduce friction between kernel policy and user-space power frameworks. Dynamic EPP previously protected itself by rejecting manual EPP writes when enabled. That remains the right general safeguard: uncontrolled competing writes create unpredictable behavior. But allowing the automatic feature to be scoped by core gives tools a clearer way to divide ownership instead of disabling Dynamic EPP across the entire system.
There is a caution here. More knobs do not automatically produce better battery life or faster systems. Poor affinity decisions can concentrate heat, worsen boost behavior, or consume more power for negligible gains. On conventional desktop PCs, the default policy may still be the best choice. Per-core tuning is most valuable where workloads are well understood and the platform has a genuine battery, thermal, or shared-power constraint.
Linux 7.3 Will Be the Test, Not the Finish Line
Linux 7.3 is still an upcoming kernel release, so the immediate next milestone is mainline integration and wider testing across Ryzen laptops and handhelds. The supplied Phoronix report establishes the feature’s direction, while the Linux kernel documentation confirms the limitation it is designed to address: Dynamic EPP currently operates as a broader automatic mode that prevents direct manual EPP changes.The key question after merge will be whether desktop distributions and handheld-focused Linux projects turn the new granularity into coherent defaults rather than another expert-only tuning file. If they do, the benefit will not be a flashy new CPU mode. It will be a quieter, longer-lasting Ryzen system that still gives its busiest core the performance it needs when it needs it.
References
- Primary source: Phoronix
Published: Fri, 31 Jul 2026 13:18:00 GMT
Linux 7.3 To Allow Tuning AMD P-State Dynamic EPP With Per CPU Core Granularity - Phoronix
Sent out last night was the last batch of planned AMD P-State driver feature improvements targeting the upcoming Linux 7.3 merge window.www.phoronix.com
- Related coverage: phoronix.com
AMD "Low Power" CPU Core Type Patches Queued Ahead Of Linux 7.3 - Phoronix
Last month I wrote bout new AMD Linux patches introducing a new 'low power' CPU core type as an alternative to their standard performance cores and dense efficiency cores - Related coverage: amd.com
AMD Technical Information Portal
www.amd.com
- Related coverage: portallinuxferramentas.blogspot.com
Linux Kernel 7.1: AMD P-State Driver Unleashes Enterprise-Grade Power Management for Ryzen & EPYC
Blog com notícias sobre, Linux, Android, Segurança , etcportallinuxferramentas.blogspot.com
