A scheduler change aimed at contention, not graphics power

The most striking Linux 7.3 gaming figures do not come from a new graphics driver, a faster rendering API or a hardware-specific optimisation. They stem from changes to the kernel scheduler: the part of Linux that decides which runnable task receives CPU time and when.

The work, known as “flatten the pick”, addresses behaviour in fair scheduling when control groups, or cgroups, are involved. Cgroups allow Linux to organise processes into groups and apportion resources between them. They are essential for containers, service management and many desktop configurations, but their hierarchical structure can make CPU scheduling decisions more complicated under contention.

For users of older or low-power machines, that complexity matters most when a game is competing with other CPU-heavy activity. Shader compilation, browser processes, file indexing, game launchers, background builds or deliberately imposed load can all cause inconsistent frame delivery even when a system’s average frame rate appears acceptable.

The proposed changes have been queued in the scheduler development tree for the Linux 7.3 cycle, but they should still be treated as upstream work in progress rather than a feature already available in mainstream distributions.

What “flatten the pick” changes

Linux’s fair scheduler uses hierarchical accounting to preserve the CPU-share rules assigned to process groups. The difficulty is that the scheduler has historically had to work through intermediate group entities while choosing the next task. Those intermediate layers can mask how many individual tasks are ready to run and add overhead or latency to the selection process.

The patch series keeps the hierarchy for load tracking and resource accounting, but moves runnable entities into a single effective queue for the EEVDF scheduling path. EEVDF, short for Earliest Eligible Virtual Deadline First, is the scheduling approach used for normal fair-share tasks in modern Linux kernels.

In practical terms, the redesign seeks to make the final choice of work less encumbered by the cgroup hierarchy. It also revises the way cgroup weight is handled, with a mode called concur becoming the intended default in the series. The objective is not to abandon cgroups or their fairness policies. Instead, it is to preserve those policies while reducing the adverse effects that can appear when a workload is divided across process groups and CPUs.

This is particularly relevant to PCs that have limited spare processing capacity. On a powerful modern desktop, inefficient scheduling may be hidden by plentiful CPU headroom. On an ageing four-core processor, a low-wattage laptop chip or a small-form-factor machine, a few poorly timed scheduling decisions can be visible as stutter, delayed input or severe one-percent-low frame-rate drops.

The benchmark is promising, but deliberately narrow

The early demonstration that drew attention used an Intel Core i7-2600K system with an AMD Radeon RX 580 and the game Shadows: Awakening running through the Linux compatibility stack. To create a difficult scenario, the test added eight CPU-bound background tasks, one for each logical processor thread on the system.

Under that artificial CPU pressure, the reported minimum frame rate rose from 3.8 frames per second to 20.6 fps. Average frame rate increased from 48.0 fps to 57.2 fps, while average frame time fell from 34.5 milliseconds to 19.5 milliseconds. The maximum frame time also dropped substantially, from 107.4 milliseconds to 37.2 milliseconds.

Those are meaningful improvements because frame-time consistency is usually more important to perceived playability than the average fps alone. A game that averages 50 fps but regularly pauses for a tenth of a second can feel worse than one with a lower average but more even delivery.

However, the results should not be read as a promise that Linux 7.3 will add similar performance to every game or PC. The test used a single older platform, one game, one graphics configuration and an intentionally hostile background-load condition. It also examined scheduler tuning in conjunction with the new work. Results can vary with CPU topology, graphics driver behaviour, game engine, power policy, memory pressure and whether a user’s setup actually exercises cgroup scheduling in the same way.

The substantial gain is therefore best understood as evidence that the current scheduler can become a bottleneck in particular contention-heavy cases, rather than proof of a universal gaming uplift.

Why low-power PCs may benefit most

The headline focus on “low-power” hardware needs some qualification. The published example used an older desktop CPU rather than a modern ultralow-power mobile processor. Still, the conclusion can reasonably extend to constrained systems because they have less room to absorb scheduling delays.

On a machine with many fast cores, the game, compositor and background services can often be placed on separate CPUs with minimal interference. A modest system must more frequently share a small pool of execution resources. If background tasks receive time at the wrong moments, the game may miss a rendering deadline even though its long-term CPU allocation is technically fair.

This is why the changes could also matter beyond gaming. Desktop responsiveness during software builds, video encoding, backup jobs or container activity depends on reducing latency spikes rather than maximising a single throughput score. The same scheduling work may improve those situations, although they require independent testing.

Adoption will take time

Inclusion in a scheduler development branch is a significant step, but it is not the final stage of kernel development. The patches must pass the Linux 7.3 merge process, survive broader testing and then be adopted by distributions. Stable enterprise and long-term-support distributions may take considerably longer to ship the work, if they ship it at all without backporting.

There is also a design trade-off. Scheduler changes affect an enormous range of machines and workloads, including servers where predictable cgroup behaviour is critical. Early discussion of the series identified performance regressions in some tests before further investigation and revisions. That is normal for core kernel work, but it reinforces the need for broad validation.

For now, the most defensible conclusion is that Linux’s upcoming scheduler work has exposed a credible route to smoother performance on CPU-constrained PCs. The dramatic figures are real for one carefully constructed test, and the underlying redesign targets a long-standing scheduling problem. Whether it becomes a broadly noticeable Linux 7.3 gaming improvement will depend on results across much more varied hardware and workloads.

Sources