Re: [REGRESSION] drm/sched: FAIR policy causes serious performance degradation at max GPU load on 9070XT
From: Philipp Stanner
Date: Mon Aug 10 2026 - 04:33:44 EST
+Cc Tvrtko
On Sat, 2026-08-08 at 23:33 +0000, 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.
>
> 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.
>
> 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.
>
> 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.
That might be the wisest thing to do; but let's hear if Tvrtko has an
idea for a hotfix first.
>
> 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.
Thanks for your effort and help. I had dared to hope that we could get
this one through without a regression, but reality always catches up..
P.