Linux 7.2 was going to ship with the fair DRM scheduler policy as its default, replacing the FIFO policy that AMDGPU and most other kernel graphics drivers have used for years. That is no longer happening. Tvrtko Ursulin of Igalia, who led the fair scheduler work, sent a nineteen patch revert series to the list on Tuesday, August 11, after a user reported that sustained GPU load on a Radeon RX 9070 XT dropped a game to roughly ten frames per second and could lock up a KDE Plasma Wayland session outright. With the 7.2 stable release expected within days, the policy is being reverted and marked experimental rather than debugged in place.
The short answer
The fair DRM scheduler policy was set to become the default in Linux 7.2, replacing FIFO across AMDGPU and the other drivers that share the kernel's DRM scheduler. A regression report against a Radeon RX 9070 XT changed that. Tvrtko Ursulin of Igalia, who led the fair scheduler work, sent a nineteen patch revert series on Tuesday, August 11, restoring FIFO and marking the fair policy experimental. With the 7.2 stable release only days away, reverting was the safe move rather than a judgement on the design.
There is a particular kind of bug report that maintainers dread, and it is not the one describing a crash. It is the one that arrives six days before a stable release, describes something intermittent, and comes with a reproduction that only says "put the GPU under load and wait."
That is the report that pulled the fair DRM scheduler out of Linux 7.2.
What was supposed to ship
The DRM scheduler is shared kernel code. When a graphics driver has work to submit to a GPU, this is the layer that decides whose work goes first, and it is used well beyond the graphics drivers people think of: AMDGPU, Etnaviv, Panfrost and Nova, plus accelerator drivers like ethosu, rocket and amdxdna.
For years it ran a FIFO policy. Jobs go in the order their virtual timestamps say they arrived, which is simple, predictable, and indifferent to whether one client is monopolising the device.
The fair policy, developed by Tvrtko Ursulin at Igalia over many review rounds, borrows from the thinking behind the CPU scheduler. Instead of pure arrival order it aims for proportional shares, so an interactive client stays responsive while a heavy background job runs. Testing had gone well, including on the Steam Deck, and no scheduling regressions against FIFO had turned up. Making it the default for 7.2 looked like the natural next step, and it landed through drm-misc-next earlier in the cycle.
The report that changed the plan
Luke Wildhardt filed the regression over the weekend, and it is worth reading closely because the shape of it is the interesting part.
Sustained full GPU load on a Radeon RX 9070 XT caused severe degradation. A game running through Proton fell to roughly ten frames per second or froze outright while its audio carried on playing. The KDE Plasma Wayland session could lock up entirely, recoverable only by rebooting or killing the compositor.
It was not just games. Leaving a game running in the background, alt tabbing out and playing a video could freeze the whole desktop.
Two details make this a scheduler report rather than an application report. Reducing the GPU load stopped the stutter immediately: alt tabbing, or opening an in game menu, was enough. And increasing the load, by turning up shadows so the frame rate dropped, reliably shortened the time to failure. Sustained saturation was the trigger, with the time to failure varying but the outcome not.
Why the revert is nineteen patches
This is the part that explains the timing pressure.
The fair policy did not arrive as a one line default change that could be flipped back. The series that introduced it also simplified the scheduler down to a single run queue, embedded that run queue singleton into the scheduler structure itself, and removed the FIFO and round robin code paths as dead code. Once the run queue count was fixed at one, the num_rqs argument that drivers passed into drm_sched_init_args had no purpose, so it was removed from every caller.
Restoring FIFO means putting all of that back. The series therefore reverts changes across amdgpu, etnaviv and the ethosu, rocket and amdxdna accelerator drivers as well as the scheduler core.
Ursulin sent the first version as twenty patches, then a v2, then a v3 trimmed to nineteen, all on the same day. Danilo Krummrich acked it and Philipp Stanner reviewed it.
The nineteenth patch is the only one that is not a revert. It marks the fair policy experimental, with a commit message as short as the situation deserves: experimental until reported regressions are addressed.
The judgement call worth noticing
With Linux 7.2 stable expected that weekend, Ursulin had two options. Debug a load dependent regression on hardware he does not have in front of him, in under a week, and ship the fix. Or revert, ship the known good policy, and take the time to do it properly.
He chose the second, and it is the right call for a reason that has nothing to do with the technical merits of either policy. A scheduler regression that only appears under sustained saturation is exactly the kind that escapes a rushed fix and lands on users instead. The fair code is not deleted, it is labelled. Nothing about the design has been walked back.
We wrote recently about Linux 7.2-rc7 arriving large and late in the cycle, and this is the same cycle continuing to be eventful right up to the release.
What this means in practice
If you run a distribution kernel, this is a story about something that will not happen to you. Linux 7.2 ships with FIFO, the same policy as 7.1, and your desktop behaves the way it already did.
The people this genuinely matters to are running 7.2 release candidates on AMD hardware today. If you are on an RDNA 4 card and have been seeing desktop freezes or severe stutter under sustained GPU load, and you have been suspecting Mesa, Proton or your compositor, this is a strong candidate for the actual cause. It resolves when the fixes land.
Driver maintainers have a smaller item to note: num_rqs is coming back, so anything rebased on top of the simplified scheduler interface needs another look.
Sources and further reading
- Linux 7.2 to revert back to the FIFO DRM scheduler policy due to fair regressions, Phoronix, August 12, 2026
- PATCH v3 00/19, Revert switching default DRM scheduler policy to fair, dri-devel, August 11, 2026
- Linux 7.2 to set default DRM scheduler priority to fair, Phoronix
- Fair(er) DRM scheduler, LWN.net
- Fair(er) DRM GPU scheduler, Tvrtko Ursulin, Igalia blog
Frequently asked questions
What does the DRM scheduler actually do, and why does its policy matter?
Every kernel graphics driver that submits work to a GPU needs to decide which client's jobs go next. The DRM scheduler is the shared piece of kernel code that makes that decision, and it is used by AMDGPU, Xe, Panfrost, Etnaviv, the Nova driver and a growing set of accelerator drivers. The policy is the rule it applies. FIFO is the simple one: jobs run in the order their virtual timestamps say they arrived. The fair policy borrows from the ideas behind the CPU scheduler and tries to give each client a proportional share of GPU time, so a background compute job cannot starve an interactive desktop. Both are defensible designs, and the policy choice is invisible until something goes wrong, at which point it is the difference between a smooth desktop and a frozen one.
What exactly did the regression look like?
Luke Wildhardt reported it against the fair policy as shipped in the 7.2 development cycle. Sustained one hundred percent GPU load on a Radeon RX 9070 XT caused severe degradation: a game running through Proton fell to roughly ten frames per second or froze outright while its audio kept playing, and the KDE Plasma Wayland session could lock up completely, needing a reboot or a compositor kill to recover. It was not confined to games either. Running a game in the background, alt tabbing away and then playing a video could freeze the whole desktop. The tell is that reducing GPU load stopped the stutter immediately, and increasing load shortened the time to failure. That pattern points at the scheduler rather than at any single application.
Why revert nineteen patches instead of fixing the one that changed the default?
Because the fair policy did not arrive as a single switch. Along with flipping the default, the series had simplified the scheduler down to one run queue, embedded that run queue singleton into the scheduler structure, removed the FIFO and round robin code paths entirely, and then removed the now unused num_rqs argument from every driver that called into the scheduler. To restore FIFO you have to put all of that back, which is why the series reverts changes in amdgpu, etnaviv and the ethosu, rocket and amdxdna accelerator drivers alongside the scheduler core. The last patch is the only one that is not a revert: it marks the fair policy experimental so the work survives while the regression is investigated.
Does this mean the fair scheduler was a bad idea?
No, and the way it was handled suggests the maintainers do not think so either. The work went through many review rounds, tested well on hardware including the Steam Deck, and no scheduling regressions were found against FIFO before this report. What happened is that a regression surfaced late in the cycle, with days left before a stable release, on a popular current generation card. Reverting under those conditions is the conservative call rather than a verdict on the design. Danilo Krummrich acked the series, Philipp Stanner reviewed it, and the fair code stays in the tree behind an experimental label rather than being deleted.
What should we do about it as users?
For almost everyone, nothing. If you run a distribution kernel you will get 7.2 with FIFO restored and the behaviour you already had on 7.1, which is the entire point of the revert. The group worth flagging is anyone running 7.2 release candidates on AMD hardware right now, particularly on RDNA 4 cards, who has been seeing desktop freezes under sustained load and blaming Mesa, Proton or their compositor. That was very likely this, and it will resolve itself when the fixes land. If you maintain a driver that calls into the DRM scheduler, the num_rqs argument comes back, so a rebase is coming.