The underlying change, reported by Phoronix and documented through Peter Zijlstra’s Linux kernel patch series, is called flatten the pick. It changes how Linux’s EEVDF scheduler selects normal tasks when CPU control groups, or cgroups, are involved. The patch has now entered the Linux 7.3 scheduler merge, meaning it is headed for the next kernel release rather than being an optional out-of-tree gaming tweak.
For Windows gamers and administrators evaluating Linux on second-life hardware, the useful takeaway is narrower and more practical: a machine that becomes unplayably stuttery when background CPU work competes with a game may behave materially better once distributions ship a Linux 7.3-based kernel. The change targets scheduler overhead and poor task selection under load; it does not add GPU horsepower, repair a CPU-bound game engine, or bypass the normal limits of an aging graphics card.
The sevenfold figure comes from one stressful test
The headline number comes from a test of Shadows: Awakening running at 1080p through Lutris, GE-Proton10-34, and the Steam Runtime on an Intel Core i7-2600K paired with an AMD Radeon RX 580. Zijlstra ran eight CPU-consuming background processes—one for each logical CPU thread—while playing, using MangoHUD to collect several minutes of frame statistics.
Under the baseline scheduler behavior, the test recorded a 4.0 FPS minimum, 47.5 FPS average, and 83.7 FPS maximum. With the scheduler work applied, the minimum rose to 29.0 FPS and average performance reached 59.2 FPS, while the maximum remained 83.7 FPS. The important result is not the unchanged peak: it is the collapse in severe stalls.
Maximum frame time dropped from 121.2 ms to 30.0 ms in the same run, while average frame time fell from 34.0 ms to 17.0 ms. Those are the figures that explain why the game could feel transformed despite the average frame rate rising by about 25 percent rather than sevenfold. A single 121 ms frame is visible hitching; a 30 ms worst observed frame is still imperfect, but far less disruptive.
The benchmark also tells readers what the result does not establish. It covers one old quad-core Sandy Bridge CPU with Hyper-Threading, one Polaris GPU, one Proton configuration, one title, and artificial CPU saturation. There is no public cross-vendor test matrix showing the same effect on modern Ryzen, Intel Core Ultra, ARM, handheld, laptop, or high-core-count desktop systems. Notebookcheck and TechPowerUp are reporting an eye-catching test result, but they are not independent replications of it.
“Flatten the pick” changes cgroup scheduling, not game rendering
The work addresses a long-standing weakness in Linux’s hierarchical cgroup scheduling. Cgroups are the kernel mechanism used to organize processes into groups and distribute CPU time, memory, I/O, and other resources. They underpin containers, system services, desktop session management, resource limits, and increasingly game-launcher or handheld tuning policies.
Before this patch series, selecting the next runnable task can involve walking intermediate cgroup entities rather than evaluating all runnable work at one level. Zijlstra’s patch retains the hierarchy for accounting, but moves the EEVDF runnable-task selection into a single runqueue. In plain terms, Linux continues to honor group structure and CPU-weight policy, but its scheduler has less hierarchy to traverse while deciding what should run next.
That matters when the system is already busy. A game, Proton processes, audio, the compositor, shader work, browser tabs, launchers, indexing, and background jobs can all compete for time. On a powerful modern CPU, the inefficiency may be difficult to notice. On a four-core processor from the Sandy Bridge era, an ill-timed scheduling delay can turn a brief contention event into a visible frame-time spike.
The patch also introduces several cgroup weight-distribution modes: up, max, concur, and tasks. Linux 7.3 changes the default to concur, which attempts a more precise representation of how many tasks within a group are runnable at once. The trade-off is explicit in the development record: concur is more computationally expensive than simpler policies, but it is intended to avoid the distorted group-weight behavior that motivated the redesign.
This is why calling the change a general “gaming FPS patch” misses the mechanism. It is a scheduler and cgroup correction with a conspicuous gaming demonstration. The potential benefit extends to any interactive workload whose responsiveness is damaged by CPU contention, although the extent of improvement outside the cited game test remains unproven.
The patch is now merged for Linux 7.3, but not yet in normal distro updates
Phoronix reported on August 19 that the scheduler changes had been merged for the Linux 7.3 merge window. That status is significant: the work has progressed past a proposal and review-stage patch series into the kernel development tree. It is also not the same as a released Linux 7.3 kernel arriving in Ubuntu, Fedora, Arch, SteamOS, or an enterprise distribution update.
The conventional kernel cycle still has to play out. Linux 7.3 will require release candidates, testing, a final upstream release, downstream distribution packaging, and then whatever validation period each distribution applies. Administrators should therefore treat this as an incoming upstream behavior change, not as an immediate setting to enable on production fleets.
That distinction is particularly important for users who run custom “gaming” kernels. Some distributions and community kernels may backport the changes early, but a backport is not automatically equivalent to the code that ultimately ships in upstream Linux 7.3. The patch touches core fair scheduling and cgroup behavior, so a local kernel experiment should be tested against the exact workloads that matter: games, virtual machines, containers, audio, remote-desktop sessions, compilers, and background maintenance.
There is also no indication that users must manually create cgroups or alter game launch commands to receive the baseline scheduler redesign. The code changes the kernel’s scheduling implementation and default cgroup mode. However, machines that never use cgroup hierarchies in a meaningful way may see less benefit than the stress test suggests, while systems with container managers, systemd service limits, desktop cgroup policies, or heavy multitasking are closer to the scenario this work is meant to improve.
The real gain is smoother performance when the CPU is already losing
The test’s fixed 83.7 FPS maximum is the clearest clue about what Linux 7.3 is—and is not—fixing. The game did not suddenly render faster when it had ample CPU time. Instead, it stopped spending as much time in catastrophic slowdowns after competing work was introduced.
That makes the update relevant to older PCs that still have capable-enough GPUs but weak CPU headroom. A Radeon RX 580 and Core i7-2600K can still run many older and less demanding titles, but modern desktop overhead, Proton translation, background services, browser processes, shader compilation, and game launchers can consume the margin that keeps frame pacing acceptable. Improving the scheduler cannot create that margin from nothing, but it can waste less of it.
For Windows users testing Linux as a way to extend older hardware, the practical comparison should be made on frame-time consistency, 1% lows, and responsiveness during real background load—not a headline FPS figure. Test with the applications actually left open: Discord or a browser, game downloads, an antivirus-equivalent scan, Steam shader processing, a recording tool, or a compilation job. The Linux 7.3 change is most likely to show its value when those competing workloads exist.
Linux 7.3’s scheduler update should therefore be read as a meaningful correction to how Linux handles cgroup-heavy contention, backed by a striking but narrowly scoped old-PC gaming test. Once distributions deliver the kernel, the concrete question for aging systems will be simple: whether the games that already nearly run well stop collapsing into stutter when the rest of the desktop gets busy.