Linux kernel developers made a significant last-minute graphics change for Linux 7.2, reverting the DRM GPU scheduler back to its previous FIFO policy by default after the newer fair scheduling implementation caused serious performance regressions. The revert was submitted just before the final Linux 7.2 release after users reported severe slowdowns and desktop freezes under sustained GPU workloads.

The decision demonstrates the kernel community’s conservative approach to regressions: when a new feature causes problems this late in a development cycle, restoring known-good behavior can be safer than rushing an incomplete fix.

What Changed in Linux 7.2?

Earlier in the Linux 7.2 development cycle, the DRM subsystem switched its default GPU scheduling policy to a new fair scheduler.

The goal was to distribute GPU execution time more fairly between competing workloads. Instead of relying on the established FIFO scheduling behavior, the new implementation uses a fairness-oriented approach designed to prevent one workload from dominating GPU resources.

However, real-world testing exposed problems that had not appeared during earlier development.

The final DRM fixes for Linux 7.2 therefore:

• Revert the fair scheduler changes
• Restore FIFO as the default
• Restore selectable scheduling policies
• Mark the fair scheduling policy as experimental

DRM maintainer Dave Airlie acknowledged that developers may have moved too aggressively when switching to the new scheduler.

AMD Radeon Gaming Exposed the Regression

The problem became particularly noticeable during gaming on an AMD Radeon RX 9070 XT.

A regression report described severe performance degradation when the GPU remained close to 100% utilization. A game running through Proton could drop to roughly 10 FPS or freeze, while audio continued playing normally.

The problem could become severe enough that the entire KDE Plasma Wayland session stopped responding, sometimes requiring the compositor to be killed or the computer to be rebooted.

Interestingly, reducing GPU load—such as by opening an in-game menu or switching away from the game—could immediately stop the stuttering.

FIFO Worked, FAIR Did Not

Testing provided strong evidence that the new scheduling policy was responsible.

The reporter compared Linux 7.2 release candidates using FAIR against configurations using the previous FIFO policy. Under otherwise similar conditions:

FAIR: reproduced the performance problem.

FIFO: survived extended stress testing without the regression.

Linux 7.1.x also behaved normally.

That comparison gave kernel developers a relatively clear indication that the scheduler transition—not simply another AMDGPU change—was behind the problem.

Why GPU Scheduling Matters

The DRM scheduler helps determine how jobs submitted by applications are sent to the GPU.

Modern Linux desktops can have numerous GPU workloads running simultaneously, including:

• Games
• Web browsers
• Video playback
• Desktop compositors
• Compute applications
• Hardware-accelerated applications

A scheduling policy therefore needs to balance throughput, latency, priority, and fairness between competing workloads.

A flaw in that behavior can have consequences well beyond gaming. In the reported case, running a GPU-heavy game in the background while playing a YouTube video could also trigger desktop problems.

Why Developers Tried Fair Scheduling

FIFO scheduling is straightforward: jobs are generally processed according to their ordering and priority queues.

Fair scheduling attempts to distribute GPU resources more evenly between competing clients. Conceptually, this can provide better behavior when several applications are submitting GPU workloads simultaneously.

The Linux DRM implementation was moving toward a virtual-runtime-based fairness model intended to prevent starvation scenarios.

The concept itself hasn't been abandoned. The problem was that the implementation wasn't considered sufficiently reliable to become the default for Linux 7.2.

A Fix Was Already Being Investigated

Developers did identify a potential partial solution while investigating the regression.

Testing indicated that an adjustment involving the scheduler's minimum virtual runtime could eliminate the severe freezes in at least some circumstances. However, some stuttering reportedly remained.

With Linux 7.2 already near its final release, maintainers faced a choice: continue debugging and introduce another late scheduler modification or revert to the known-working implementation.

They chose the safer option.

A 20-Patch Revert

Undoing the scheduler transition wasn't as simple as changing one line.

A 20-patch series was prepared to unwind the related DRM scheduler changes and restore the previous architecture. The series reversed modifications affecting the core scheduler as well as numerous GPU and accelerator drivers.

Affected areas included drivers for AMDGPU, Xe, Nouveau, Panfrost, V3D, MSM, Lima, Etnaviv, and other DRM or accelerator components.

The final result restores the previous scheduling infrastructure while keeping FAIR available for additional development and testing.

Fair Scheduling Becomes Experimental

Importantly, Linux developers aren't eliminating the fair scheduler entirely.

Instead, the Linux 7.2 fixes explicitly mark FAIR as experimental.

That allows developers and interested users to continue testing the technology without exposing every Linux 7.2 user to an implementation that has already demonstrated significant regressions.

Once the remaining problems are understood and resolved, fair scheduling could potentially return as the default during a future kernel cycle.

Other Last-Minute DRM Fixes

The scheduler revert arrived as part of a larger DRM fixes pull request for the final Linux 7.2 release.

The update also contained fixes for:

• AMDGPU
• Intel Xe graphics
• HDMI audio information handling
• DRM logging
• Radeon runtime power management
• AMD XDNA

Several bounds-checking, memory-safety, display, power-management, and error-handling issues were addressed as well.

So while the scheduler change attracted the most attention, it was only one part of a substantial late graphics update.

What Linux Gamers Need to Know

For most Linux gamers, the revert is good news.

Users running the final Linux 7.2 kernel should get the established FIFO scheduler behavior by default rather than automatically being moved onto the problematic FAIR implementation.

That is especially relevant for gamers using AMD Radeon GPUs under heavy loads, where the regression was initially demonstrated.

There is no indication that users need to abandon Linux 7.2 because of this issue—the problematic default was reverted before it could become the normal behavior of the final kernel.

Conclusion

Linux 7.2's last-minute DRM scheduler reversal is a good example of how kernel development handles serious regressions. Fair GPU scheduling promises advantages for systems running multiple competing graphics workloads, but the implementation proved problematic under sustained real-world GPU loads.

Rather than ship a potentially disruptive scheduling change and fix it afterward, maintainers restored FIFO as the default and moved FAIR back to experimental status.

The fair scheduler isn't dead. Developers are already investigating fixes, and it may return once the remaining performance and stability problems are resolved. For Linux 7.2, however, stability won over introducing a new scheduling model at the last minute.