Graphics drivers in the Linux kernel just got a timely boost. A fresh set of changes to the shared DRM scheduler promises to cut job submission latency dramatically when the CPU runs hot with dozens of runnable processes. The work comes from Tvrtko Ursulin at Igalia, who posted an RFC on the dri-devel mailing list only hours ago.
Current code relies on kernel workqueues for certain asynchronous tasks inside the scheduler. That choice works fine on quiet systems. But overload the CPU and even a high-priority graphics client can see its GPU submissions delayed. The scheduler ends up waiting behind other kernel threads. Frames drop. Compositors stutter. Gamers notice. Desktop users feel the hitch.
Ursulin’s patches swap those workqueues for kthread_work. The switch looks small on paper. Results say otherwise. Early tests with the Panthor Arm Mali driver show what Phoronix described as a “striking improvement” in submission latency. Other drivers such as AMDGPU may see less dramatic gains since they already adapted parts of the path. Intel’s Xe driver stands to benefit once updated. Phoronix reported the RFC and benchmark hints.
“This is obviously really good for preventing compositors from missing frames and similar,” Ursulin wrote in the cover letter. Simple words. Big implication for everyday Linux desktops.
The change arrives against a backdrop of broader DRM scheduler evolution. For years the default policy stayed FIFO. First-in, first-out sounds fair until real workloads collide. A heavy compute job could starve an interactive client. Priority queues helped but introduced starvation of lower-priority work despite Vulkan’s explicit allowance for some skew in global priority extensions.
Enter the fair scheduler. Ursulin first floated the idea in a June 2025 blog post. He modeled it after the kernel’s own Completely Fair Scheduler for CPUs. Instead of submission timestamps, the code now tracks virtual GPU time. Real runtime gets scaled by a priority factor. The run queue, still an rbtree, sorts entities by this virtual time. Pick the one with the least so far. Simple. Effective.
“The virtual GPU time selection criteria largely decouples the scheduling decisions from job submission times, to an extent from submission patterns too, and allows for more fair GPU time distribution,” he explained in that post on his Igalia blog. Tests on a Steam Deck told the story clearly. Three clients ran together: a low-priority Vulkan demo, a normal-priority version of the same, and the Unigine Heaven benchmark. Under FIFO the low-priority task starved completely. The fair approach gave each a share. Graphs showed nearly equal GPU time distribution with the low-priority client finally moving forward.
Synthetic workloads reinforced the pattern. Heavy hogs versus interactive clients. Deep submission queues. Mixed priorities. In each case the new policy delivered steadier progress and higher frame rates for the interactive side. One test showed roughly triple the FPS for an interactive application when the GPU sat oversubscribed. LWN covered the v5 patch series in detail last year, highlighting both the fairness gains and the code cleanup. Multiple run queues and scheduling algorithms disappeared. One queue remained. Future cgroup-based controls suddenly look practical because virtual time already exists. LWN detailed the tests and developer feedback.
By April 2026 the momentum had built. A pull request for Linux 7.2 proposed making the fair policy the default. Ursulin’s own words in that thread left little doubt. “FAIR policy works better than FIFO for all known use cases and either matches or gets close to RR. Lets make it a default to improve the user experience especially with interactive workloads competing with heavy clients.” Phoronix picked up the story, noting months of prior work and visible gains already on the Steam Deck. The default switch landed. Phoronix covered the Linux 7.2 DRM changes.
Yet the latency problem under CPU overload persisted in certain paths. Today’s RFC targets exactly that gap. The scheduler still uses workqueues for job submission in some drivers. When the system load average climbs and the CPU scheduler spreads runnable tasks across cores, those workqueues compete with everything else. High-priority GPU clients suffer. Kthread_work runs in a dedicated thread context. It sidesteps much of that contention. The RFC includes adaptations for Intel Xe and Panthor. Others will follow if reviews go well.
Developers have spent years refining this scheduler. Early versions focused on basic job ordering. Later patches added priority support, dependency tracking via dma-fences, and entity management. Each step removed assumptions that worked on single-user machines but crumbled under modern desktop and laptop loads. Preemption remains missing on many GPUs, so perfect fairness stays out of reach. Still, the virtual-time approach gets remarkably close without it.
And the timing feels right. Desktop Linux continues to gain in gaming and content creation. Steam Deck success showed the platform can handle demanding 3D workloads. Ray tracing, AI upscaling, multiple monitors. All increase pressure on the scheduler. A compositor that misses frames because the kernel queued its work behind a background compile job no longer feels acceptable.
Reviews will decide how quickly these latency patches reach mainline. The fair scheduler already sits in 7.2 as default for drivers that opt in. Together the two efforts point toward a scheduler that behaves more predictably whether the machine runs one task or fifty. Code gets simpler. Behavior gets clearer. Users see fewer stutters.
Ursulin invited testing on different GPUs and submission patterns. Hardware vendors and open-source contributors will likely answer. Panthor already demonstrates the latency win. AMD and Intel drivers could show complementary gains in mixed workloads. The RFC links back to the fair scheduler series for context. One builds on the other.
Expect more patches in coming weeks. Kernel 6.16 or 6.17 might carry the kthread_work conversion if momentum holds. The fair default already ships. For desktop users that combination could translate into noticeably smoother experiences when the CPU runs flat out. No marketing slogans needed. Just fewer dropped frames and quicker response when it matters most.
WebProNews is an iEntry Publication