Linux 7.3: 'Flatten the Pick' Scheduler Gains for Gaming

What Does 'Flatten the Pick' Mean in the Linux Scheduler?

The Linux kernel scheduler makes one decision thousands of times per second: which runnable task gets CPU time next. The speed and consistency of that decision is what separates a desktop that feels instantaneous from one that micro-stutters under load.

Linux 7.3 is expected to ship a cluster of patches collectively described on the Linux Kernel Mailing List (LKML) as "flatten the pick" — a refactoring of the pick_next_entity() function inside the EEVDF (Earliest Eligible Virtual Deadline First) scheduler. EEVDF replaced the long-running Completely Fair Scheduler (CFS) in Linux 6.6, and per Phoronix's coverage of that transition, the migration delivered measurable improvements in scheduling fairness and wakeup latency across mixed-workload desktops.

The flatten-the-pick work targets a structural inefficiency that EEVDF inherited from CFS: the task-group tree hierarchy. When Linux needs to schedule the next runnable task, pick_next_entity() traverses multiple scheduling groups — one per cgroup level — before it can select a task. On a typical systemd-based Linux desktop, this means several levels of conditional branch evaluation for every scheduling decision. Each level adds memory accesses and branch mispredictions that, individually, are nanosecond-scale. Multiplied across thousands of scheduling events per second during a frame-rendering loop, they accumulate into measurable overhead.

The patches linearize this traversal, reducing it to a flatter walk through the scheduling tree without altering the core EEVDF principle: the eligible task with the earliest virtual deadline still wins. Per LKML patch discussion threads, the change is purely an implementation optimization — the scheduler's fairness guarantees and deadline semantics are preserved exactly.

For gaming, this matters because the game main loop is effectively a real-time workload. Submit draw calls. Wait for GPU completion. Process input. Repeat at 60–240Hz. Any per-iteration overhead in the scheduler's pick path contributes to frame-time variance — the variance that produces micro-stutters even when average FPS looks fine.

Why Gaming Performance Is Scheduler-Sensitive

The connection between kernel scheduler overhead and gaming performance is less obvious than GPU driver improvements, but it is well-documented in the Linux benchmarking community. Phoronix's longitudinal kernel benchmark series has tracked scheduler-related improvements through the entire 6.x cycle, and the pattern is consistent: changes that reduce scheduling tail latency disproportionately improve minimum frame times and 1% lows rather than average frame rates.

The mechanism is straightforward. A game engine's main thread runs on a tight cadence. When the GPU finishes rendering a frame, it fires a completion interrupt. That interrupt wakes the game thread, which then processes the result and submits the next frame. The latency of that wakeup — from interrupt to the game thread scheduled back onto a CPU core — is partly a function of pick_next_entity() overhead. Flatten the pick path, and frame delivery becomes more consistent.

This is distinct from raw throughput improvements. Average FPS depends primarily on GPU compute capacity and driver efficiency. Frame-pacing consistency depends on whether the CPU delivers work to the GPU on a regular cadence — and that cadence is set by the scheduler.

For context on how much the platform matters, see our Linux vs Windows 11: AMD Ryzen 9 9950X3D Performance analysis, which documents how kernel-level differences between operating systems translate into measurable frame-time divergence on identical hardware.

AMD GPU and AMDGPU Driver Interaction

AMD's open-source AMDGPU stack is where the flatten-the-pick change intersects most directly with GPU hardware. The AMDGPU kernel driver submits command buffers through the DRM (Direct Rendering Manager) hardware scheduler, which in turn relies on the kernel task scheduler to deliver completion events back to the requesting thread. The round-trip — game thread submits draw call → GPU executes → completion interrupt → DRM wakes the game thread → kernel scheduler picks it — passes through pick_next_entity() on the final hop.

For AMD RDNA 3 and RDNA 4 GPUs, which support parallel compute and graphics queue dispatch, the completion event frequency is higher than on older hardware — more queues means more concurrent completions, each requiring a scheduler wakeup. Reduced pick-path overhead compounds across all of them.

Per Phoronix's AMDGPU performance coverage through the 6.x cycle, scheduler-side improvements have historically shown the largest per-frame gains in scenes with high GPU–CPU synchronization frequency: physics-heavy simulations, ray-traced shadow passes, and high-frequency GPU readback operations. These are also the scenarios where frame-time variance is most visible to players.

This is also relevant for workstation-class AMD hardware. Pro GPUs running long-duration compute jobs compete with interactive desktop tasks at the same scheduler level. Reduced pick overhead benefits render queue processing throughput — the same mechanism, applied to a different workload class.

For another example of how low-level CPU feature improvements translate to real Linux workload gains, see AVX-512 Speeds Up Linux Software RAID by Up to 41% on AMD Ryzen.

Linux Scheduler Evolution: 6.6 Through 7.3

The trajectory reflects consistent incremental refinement rather than single dramatic leaps. The EEVDF transition in 6.6 was the largest structural change to the Linux scheduler since the CFS era; subsequent releases have tightened implementation details. Per Phoronix's longitudinal benchmarks, the gains are cumulative — a system running Linux 7.3 carries every improvement from the 6.6 migration forward.

For context on what the 6.18 generation delivered at the platform level, see Raspberry Pi OS Now Ships on Linux 6.18 LTS With Performance Gains and Raspberry Pi OS Moves to Linux 6.18 LTS: What Changes for Pi Builders.

What Hardware Benefits Most

Not all systems benefit equally from a flatter pick path. The gains are largest where the scheduler's pick function is invoked most frequently and under the most contention:

High-core-count AMD Ryzen systems. More cores means more concurrent runnable tasks, which means more invocations of pick_next_entity() per second. Systems running AMD Ryzen 9 9950X3D or similar high-CCD configurations — where the scheduler balances tasks across multiple CCDs with NUMA-like topology — see proportionally larger reductions in per-scheduling-event overhead.

Desktops running background workloads alongside games. A gaming desktop with Steam updating, browser tabs open, and system daemons active creates exactly the mixed-priority task queue the flatten patches optimize for. Per Phoronix's benchmark methodology, background compile workloads running concurrently with games are the canonical stress case for scheduler overhead — and the scenario where flatten-the-pick gains are most visible.

Multi-monitor and variable-refresh setups. Each active display runs a compositor with its own real-time scheduling requirements. With multiple VRR displays, the scheduler handles higher interrupt rates and more frequent wakeup events, amplifying any overhead in the pick path.

ARM and embedded platforms. The EEVDF scheduler and its flatten-pick optimizations are architecture-agnostic, which means platforms from high-core-count Ryzen workstations down to embedded Linux boards benefit from reduced per-tick overhead. Even experimental ports — like the Linux boot demonstrated on a Sega Genesis — inherit these improvements.

Gaming Scenarios: Where to Expect the Difference

For a real-world latency-sensitive Linux I/O scenario, see 4K@60fps USB Video Capture on Linux: What Works in 2024, which covers a class of workloads where scheduler wakeup latency is similarly critical.

How to Get These Improvements Before Linux 7.3 Releases

Linux 7.3 is not yet released as of this writing — patch series are tracked in LKML and the tip/sched/core development tree. Per the Linux kernel development cadence, each major kernel version sees a roughly 9-to-10-week development window followed by a stabilization period. The 7.x branch timeline depends on when 7.0 is tagged.

Users who want early access have several options:

Distribution kernels with backports. Arch Linux, Fedora Rawhide, and openSUSE Tumbleweed track mainline closely and often carry scheduler patches from the development tree ahead of stable release. Checking a kernel's patch changelog for sched/fair: flatten entries indicates whether the specific optimization has been backported.

linux-zen and CachyOS kernel. Community-maintained kernel variants like linux-zen and the CachyOS kernel already ship aggressive scheduler patches — BORE (Burst-Oriented Response Enhancer) and latency-tuned EEVDF configurations — that address the same overhead class as flatten-the-pick. Per community comparisons on the Phoronix forums, these variants measurably improve 1% lows in frame-time benchmarks for gaming workloads on identical hardware.

Custom kernel builds from tip/sched/core. Phoronix's testing methodology commonly involves building kernels directly from the scheduler development branch. This is the fastest path to unreleased patches but requires a working kernel build environment.

For users building dedicated Linux gaming machines, peripheral compatibility is worth verifying across kernel versions. USB-connected Linux-compatible hardware — such as the UGREEN USB to Ethernet Adapter, which uses the AX88772D chipset with long-standing mainline support — remains stable across kernel updates since these use stable USB stack drivers that are not affected by scheduler refactoring.

Intel Arc and the Broader Linux GPU Ecosystem

The flatten-the-pick improvement is not AMD-exclusive. Any GPU driver that routes command completion through the DRM scheduler benefits from reduced kernel task-scheduler overhead on the CPU side. Intel's Arc GPU stack — covered in Intel Arc Pro B70 Linux Gaming Performance 2026 — uses the same DRM completion path, and the i915/Xe driver team has been an active contributor to DRM scheduler improvements alongside the AMD team.

NVIDIA proprietary driver users are less directly affected, since the proprietary stack manages its own scheduling layer outside the mainline DRM scheduler. However, systems using Nouveau or NVK (the open Vulkan driver) do benefit, and the GPU-independent aspects of the flatten-the-pick improvement — reduced CPU overhead during game main loop scheduling — apply regardless of GPU vendor.

Citations and sources

• https://www.phoronix.com/ — Phoronix Linux kernel benchmark coverage: EEVDF scheduler migration, sched/fair patch series, gaming and workstation longitudinal benchmarks
• https://lkml.org/ — Linux Kernel Mailing List: sched/fair flatten-the-pick patch threads, EEVDF development history
• https://www.kernel.org/ — Linux kernel stable releases, development tree, and scheduler subsystem documentation

This piece is editorial synthesis based on publicly available information. No independent first-party benchmarking is reported.