Linux kernel developer David Vernet posted an RFC patch on July 28, 2026, adding per-core EPP boost to "amd-pstate," the frequency control driver for AMD CPUs. Running the built-in benchmark for "Civilization VI" on a Steam Deck OLED showed a 31.8% improvement in the 1% Low. Meanwhile, average fps and p999 frame time—which represents the slowest tail—showed no change. This is not a change that speeds up the entire Steam Deck by 32%, but rather a proposal aimed at the behavior where CPU clocks fail to recover after a short wait, resulting in slow frames.
The patch is still at the RFC stage, seeking feedback. Adoption into mainline Linux or SteamOS has not been decided. Moreover, after posting, the author corrected himself, noting that the measurement device was actually the OLED model rather than the LCD model. Rather than the magnitude of the number itself, what matters is which latency was reduced and how, and whether the implementation is compatible with current power control.
Targeting Slow Frames, Not Average fps
The 31.8% figure is limited to a single Steam Deck OLED unit and a single title. The Van Gogh APU was run in amd-pstate's active mode with EPP=balance_performance, using the graphics benchmark for "Civilization VI," which depends on single-threaded CPU performance. Each configuration was run six times in alternating order, and differences were evaluated using Welch's t-test.
The results were as follows.
| Configuration | Median frequency on the heavily-loaded core | Change in frame time metrics |
|---|---|---|
| Default | 2.43GHz | Frequency doesn't increase even when render thread execution rate is 98% |
| All cores set to EPP=performance | 3.5GHz | 1% Low improved by about 16%, p999 shortened by about 40% |
| Raising min_perf on heavily-loaded core to nominal | 3.5GHz | p999 worsened by 13-21% |
| Per-core EPP boost | 3.5GHz | 1% Low improved by 31.8%, p99 improved by 4.1% |
The difference for per-core EPP boost carries a p-value of 0.014 for 1% Low and 0.015 for p99 frame time. However, average fps and p999 remained unchanged. Rather than increasing the total frame count, the result was a lightening of some of the heavier tail. Therefore, the effect shows up more in perceived stutter than in average fps.
EPP Control at 10ms, 50%, and 300ms
EPP stands for Energy Performance Preference, a hint that tells the CPU whether to prioritize performance or power savings. In amd-pstate's active mode, the OS passes minimum and maximum performance along with EPP, and the platform side selects the actual operating point within that range. The Steam Deck OLED's CPU officially operates within a 2.4-3.5GHz range, with the entire APU operating within a 4-15W envelope.
The proposed epp_boost checks how much time each core was actually running at intervals of up to 10 milliseconds. If the utilization rate is 50% or higher, only that core's EPP is switched to performance's value of 0. If high-load samples are interrupted for 300 milliseconds, it reverts to the value specified by the user or power profile.
This implementation does not raise the minimum performance (min_perf). It does not touch maximum performance or requested performance either, only rewriting the CPPC request when a core becomes heavily loaded and when it becomes idle. This is a more targeted approach than pushing all cores to performance at all times, aiming to avoid spreading power to background cores on a handheld device where CPU and GPU share the same power envelope.
However, this is only available on systems using amd-pstate's active mode with support for CPPC via MSR. Shared-memory CPPC is excluded, as it cannot access registers the same way during scheduler processing. The patch itself is opt-in and won't function unless explicitly enabled.
Dropping to About 2.4GHz After a 0.2ms Pause
In response to feedback on the RFC, Vernet obtained three additional 60-second traces. Reading APERF/MPERF for all 8 CPUs at 1-millisecond intervals and overlaying thread-switch and CPU idle records revealed that immediately after the render thread paused for more than 0.2 milliseconds, the effective clock of the heavily-loaded core dropped from 3.5GHz to about 2.4GHz. Even after recovery, it remained low for at least 8 milliseconds, sometimes continuing for several seconds. This behavior persisted even when CPU idle states were restricted to only POLL and C1.
Game main threads and render threads sleep briefly each frame while waiting on futexes or GPU fences. Vernet explains that this wait weakens the hardware's performance signal, causing work immediately after recovery to begin at a lower frequency, which extends the tail of frame times. epp_boost leaves a performance hint on cores that were recently busy, speeding up this recovery.
Another measurement showed that simply raising the minimum performance isn't necessarily the answer. The approach of raising min_perf on the heavily-loaded core to nominal also reached a median of 3.5GHz, but p999 worsened by 13-21%. The author believes that since CPU and GPU share an SMU-managed power envelope, pinning the CPU to a high level even during short waits may reduce headroom on the GPU side. However, confirmation of this causal relationship through GPU frequency and power consumption has not yet been completed.
The RFC's Hurdle: User-Set EPP and Alternative Approaches
In review, the question of who bears responsibility for control arose before the effectiveness itself. AMD's K Prateek Nayak pointed out that if the kernel temporarily changes EPP that userspace tuning tools have explicitly set, this conflicts with what existing tools expect. AMD's Mario Limoncello also questioned whether the implementation might end up competing with hardware in active mode, suggesting that passive or guided mode might be more appropriate.
An alternative approach combines passive mode with schedutil, setting UCLAMP_MIN for important threads. This directs minimum performance requests through the scheduler rather than directly overriding EPP, but Vernet has not yet tested this on the Steam Deck. However, Vernet points out that Proton does not implement the Windows API compatibility feature for identifying render threads, meaning some other mechanism would need to determine which threads to prioritize.
Vernet lists comparisons with guided/passive mode, UCLAMP_MIN, and Dynamic EPP, along with follow-up testing using synthetic loads and turbostat. What's needed is confirmation of whether 1% Low improves on other games and AMD APUs, whether power consumption can be reduced without changing average fps, and whether the design can be made to avoid conflicting with user settings. Only after passing through this gate could the limited experiment showing 31.8% become a candidate for implementation in SteamOS.