Re: [REGRESSION] drm/sched: FAIR policy causes serious performance degradation at max GPU load on 9070XT
From: Tvrtko Ursulin
Date: Tue Aug 11 2026 - 03:47:07 EST
On 09/08/2026 00:33, Luke.Wildhardt@xxxxxxxxx wrote:
Since the DRM scheduler default policy was switched to FAIR in 7.2, sustained 100% GPU load in-game on my RX 9070 XT causes severe performance degradation. In the example title running through Proton, Project Silverfish, the foreground application degrades to roughly 10 fps or freezes outright while audio continues, and the KDE Plasma Wayland session can lock up entirely, requiring a reboot or killing the compositor to recover. The problem is not limited to games. Running the game in the background + alt tabbing, then playing a YouTube video can also cause the entire desktop to freeze.
Was there anything interesting in dmesg then the total UI lockup happened?
Then, if the game starts to stutter, either alt-tabbing, or opening up a menu in game (which reduced the load on the GPU) immediately stops the stuttering.
The issue is reliably reproducible under sustained GPU saturation, although the time-to-failure varies. Increasing shadow load (which decreases in-game frame rate) substantially shortens the time-to-failure.
In game, MangoHud does not reveal any frametime discrepancy.
What exactly did you mean by not revealing discrepancy? Game is at 10fps and HUD shows 10fps? Or game appears to stutter but HUD shows "normal" fps?
Bisection / test matrix
Reproducer: Project Silverfish (Proton) at settings that saturate the GPU, with a second GPU client active (browser video). Other titles show the same symptom under sustained load; I have not yet re-tested those specific titles against the fix.
Could you list the other titles which showed the issue?
Regards,
Tvrtko
Kernel Result
torvalds/master stock FAIR (default) FAIL
same as above + reverts below gpu_sched.sched_policy=2 (FAIR) FAIL
same as above + reverts below gpu_sched.sched_policy=1 (FIFO) PASS
7.1.5 release PASS
drm-next FAIR (default) FAIL
Reverted Commits:
d09339388b77 drm/sched: Remove drm_sched_init_args->num_rqs
2833a0512b4c drm/sched: Remove drm_sched_init_args->num_rqs usage
16e7698bc04d drm/sched: Embed run queue singleton into the scheduler
77a6809f1dc3 drm/sched: Remove FIFO and RR and simplify to a single run queue
45c211ddf92a drm/sched: Switch default policy to fair
2462a0ce23b0 drm/amdgpu: Remove drm_sched_init_args->num_rqs usage
Kernel (failing): 7.2.0-rc6 (stock), also current drm-next
Kernel (working): 7.2.0-rc6-default-revert-00006-g7e5de9b07e3d with sched_policy=1
7.1 release
Distro: Arch Linux
Session: KDE Plasma 6.7.4 / Wayland (KWin), Qt 6.11.1, KF 6.28.0
CPU: AMD Ryzen 9 9950X3D
RAM: 64 GiB
GPU: Sapphire Pulse Radeon RX 9070 XT
03:00.0 [1002:7550] rev c0, subsys Sapphire 1478
Motherboard: ASUS (AM5 / 800-series chipset)
Mesa: 26.1.6-arch1.1 (RADV, driverVersion 26.1.6)
Vulkan: instance 1.4.357 / device 1.4.354
On the same reverted kernel build, changing only gpu_sched.sched_policy from 2 (FAIR) to 1 (FIFO) changes the result from reliably failing to passing extended stress testing.
Possible mitigation options
Given that 7.2 is late in the release cycle and 77a6809f1dc3 removes FIFO/RR as selectable policies, there is currently no runtime workaround for affected systems.
Revert 45c211ddf92a so FIFO remains the default while FAIR remains available for further testing.
If necessary, also revert 77a6809f1dc3 and dependent changes to restore runtime policy selection.
Alternatively, fix the underlying FAIR regression if a suitable fix can be identified in time for 7.2.
I mention the revert options because the justification for removing FIFO/RR included the absence of known regressions relative to those policies. This report appears to provide at least one counterexample.
I am willing to test patches responsively and collect data if necessary.