Linux 7.3 changes how the scheduler handles cgroups, and if you run containers that sentence matters more than it looks. Peter Zijlstra's rework, merged during the 7.3 window and reported on Wednesday, August nineteenth, 2026, moves EEVDF onto a single runqueue in certain cgroup situations and introduces four weight distribution modes named up, max, concur and tasks, with concur as the default. The pull request is unusually blunt about why, describing cgroup scheduling as problematic and painful and blaming it for misbehaviour such as the mishandling of reniced tasks. The demonstration used a decade old gaming rig, but the code path is the one every container on your fleet runs through.
The short answer
Peter Zijlstra's cgroup scheduling rework merged during the Linux 7.3 window and was reported on Wednesday, August nineteenth, 2026. EEVDF now uses a single runqueue in certain cgroup situations, and four weight distribution modes named up, max, concur and tasks were added, with concur as the default. On an Intel Core i7-2600K with a Radeon RX 580, minimum frame rate rose from 4 to 29 fps and maximum frame latency fell from 121.2 ms to 30 ms. No configuration change is required.
The interesting part of this merge is not the frame rate. It is the sentence in the pull request admitting that cgroup scheduling has always been painful.
What merged
Peter Zijlstra, the Intel engineer who maintains the Linux scheduler, landed a cgroup scheduling rework in the Linux 7.3 merge window. Reporting appeared on Wednesday, August nineteenth, 2026.
The structural change is that cgroup scheduling now uses a single runqueue. More precisely, EEVDF, the Earliest Eligible Virtual Deadline First policy that replaced the Completely Fair Scheduler, is modified to rely on one runqueue in certain cgroup situations rather than resolving decisions through a nested hierarchy of group entities.
On top of that sit four weight distribution modes, added under a cgroup_mode control and named up, max, concur and tasks. Concur is the default and is described as the most precise version, and also as the most expensive. That pairing is the whole design conversation in one line: the kernel is choosing correctness first and offering the cheaper options to anyone who measures a reason to want them.
The stated motivation is not subtle. The work is summarised as improving cgroup scheduling, which has always been problematic and painful, and which has caused various scheduling misbehaviour such as the mishandling of reniced tasks. Anyone who has watched a nice value quietly fail to do anything useful inside a container will recognise the complaint.
The numbers, and how to read them
The demonstration ran on an Intel Core i7-2600K, a Sandy Bridge processor from 2011, paired with an AMD Radeon RX 580.
Minimum frame rate went from 4 to 29 frames per second. Average frame rate went from 47.5 to 59.2. Maximum frame latency dropped from 121.2 milliseconds to 30 milliseconds.
The shape of those numbers is more informative than their size. The average improved by about a quarter. The minimum improved by roughly seven times and the worst case latency by roughly four. When the tail moves far more than the mean, you are looking at a jitter fix, not a throughput fix, and jitter is exactly what a nested weight hierarchy produces when it has to resolve a scheduling decision under contention.
That is also why a gaming benchmark is a reasonable instrument here even for people who never play games. Frame pacing makes scheduling jitter visible to the naked eye at millisecond resolution, which very few server metrics do. The game is a measuring device.
Why this lands on servers, not just desktops
Every container you run lives in a cgroup. So does every systemd service, on any modern distribution, whether or not anyone made a deliberate decision about it. The cgroup scheduling path is not an optional subsystem you can decline; it is the ordinary path.
The consequence is that a jitter reduction in cgroup weight resolution reaches almost everything. A latency sensitive service sharing a node with a noisy batch job is precisely the contention case the rework targets. So is the classic complaint where a container gets its CPU shares in aggregate but individual requests still show a bad ninety ninth percentile.
The reniced tasks detail deserves its own note. If your orchestration or your runbooks lean on nice values to keep background work out of the way, the pull request is telling you that behaviour has been unreliable under cgroups. Worth rechecking after the upgrade, because a nice value that starts working properly is also a nice value that starts having an effect you may not have planned for.
None of this requires configuration. Concur is the default, and the reported gains come from the default path. The other three modes are there for later, once someone has characterised where the precision is not worth the cost.
The rest of the scheduler pull
The cgroup rework arrived alongside enough other scheduler work that the whole cycle deserves attention before a fleet wide upgrade.
Vincent Guittot contributed changes that noticeably lower scheduling latency for short slice tasks, measured with cyclictest, which is the most directly relevant item for anyone running real time adjacent or latency sensitive services. There is a fix to cluster scheduling on CPUs with asymmetric capacity, meaning Intel hybrid parts, continuing a thread this cycle has returned to more than once and which we covered when the balancing fix was first queued for 7.3. And NOHZ balancing now prefers fully idle cores, which tends to show up in tail latency rather than in a headline figure.
CachyOS, the performance oriented Arch derivative, has said it plans to pick up these changes, without giving a timeline. That is usually the fastest route to trying them on real hardware without building a kernel yourself.
Timing and a suggestion
Linux 7.2 was released in mid August 2026, so 7.3 is early in its cycle and a stable release is roughly two months out. The 7.2 cycle itself was not quiet on the scheduler, including a revert of the fair DRM scheduler work, which is a useful reminder that scheduler changes of this size sometimes need a second pass.
The suggestion is simple and it is the same one that applies to any scheduler rework. Capture your scheduling latency now, on 7.2, using something you already trust. Cyclictest for the raw number, or your own ninety ninth percentile request latency on a node under normal load. When 7.3 reaches you, compare against that. A rework this structural will help most workloads and will surprise a few, and the only way to know which one you are is to have measured before.
Sources and further reading
- Linux 7.3 Scheduler Improvements: Help For Gaming, Hybrid CPUs, Lower Scheduler Latency, Phoronix, August 19, 2026
- Linux 7.3 patch brings 7x higher minimum FPS in games running on old hardware, Notebookcheck, August 20, 2026
- Linux 7.3 will boost minimum framerates by 7x on older CPUs, XDA Developers, August 2026
- EEVDF, Linux Kernel Internals reference
Frequently asked questions
What is the actual change to the scheduler?
Two things, and they are related. The first is structural: cgroup scheduling now uses a single runqueue rather than the nested per group structure it relied on before, which means EEVDF, the Earliest Eligible Virtual Deadline First policy that replaced CFS, makes its decisions over one ordered set of entities in the affected cases instead of walking a hierarchy. The second is a set of weight distribution modes, up, max, concur and tasks, that control how a cgroup's weight is spread across the CPUs its tasks are running on. The default is concur, described as the most precise and also the most expensive of the four. The practical effect reported is a large reduction in rescheduling jitter.
Why does a gaming benchmark tell me anything about my servers?
Because the workload is incidental and the code path is not. The test that produced the headline numbers happened to be a game on old hardware, which is a good stress case for scheduler jitter because a dropped frame is immediately visible. What was actually being measured is how long a runnable task waits when cgroup weights have to be resolved across a hierarchy. Every container runtime puts its workloads in cgroups, and so does systemd for ordinary services. If you have ever seen a latency sensitive service in a cgroup behave worse than the same binary run outside one, this is the machinery involved. The frame rate is a proxy, not the point.
What numbers were actually reported?
On an Intel Core i7-2600K, a processor from 2011, paired with an AMD Radeon RX 580, minimum frame rate rose from 4 to 29 frames per second, roughly seven times. Average frame rate went from 47.5 to 59.2. Maximum frame latency dropped from 121.2 milliseconds to 30 milliseconds. Read the minimum and the maximum latency rather than the average: the average moved about 25 percent while the worst case moved by a factor of four, which is the signature of a jitter fix rather than a throughput fix. There is no published equivalent measurement for server workloads yet, which is the main reason to benchmark rather than to assume.
Do I need to change any configuration?
No. Concur is the default and the reported improvements come from the default path, so an upgrade is sufficient to get the behaviour. The other three modes exist because concur is also described as the most expensive of the four, which implies there are workloads where trading some precision for lower overhead is the right call. That tradeoff is not yet characterised publicly for server workloads, so the sensible posture is to take the default, measure your own scheduling latency, and only reach for another mode if you have a number that justifies it.
What else landed in the same scheduler pull?
Vincent Guittot's work lowering scheduling latency for short slice tasks, measured with cyclictest, which is directly relevant to anyone running latency sensitive services. A fix to cluster scheduling on CPUs with asymmetric capacity, meaning Intel hybrid processors, which has been a recurring theme this cycle. And a change to prefer fully idle cores when doing NOHZ balancing, which is the sort of adjustment that shows up as slightly better tail latency rather than as a headline. Taken together this is a heavier scheduler cycle than usual, which is worth knowing before you upgrade a fleet in one pass.