Re: drm_sched run_job and scheduling latency

Matthew Brost
2026-03-05T02:04:35Z

On Wed, Mar 04, 2026 at 02:51:39PM -0800, Chia-I Wu wrote:
> Hi,
>
> Our system compositor (surfaceflinger on android) submits gpu jobs
> from a SCHED_FIFO thread to an RT gpu queue. However, because
> workqueue threads are SCHED_NORMAL, the scheduling latency from submit
> to run_job can sometimes cause frame misses. We are seeing this on
> panthor and xe, but the issue should be common to all drm_sched users.
>

I'm going to assume that since this is a compositor, you do not pass
input dependencies to the page-flip job. Is that correct?

If so, I believe we could fairly easily build an opt-in DRM sched path
that directly calls run_job in the exec IOCTL context (I assume this is
SCHED_FIFO) if the job has no dependencies.

This would likely break some of Xe’s submission-backend assumptions
around mutual exclusion and ordering based on the workqueue, but that
seems workable. I don’t know how the Panthor code is structured or
whether they have similar issues.

I can try to hack together a quick PoC to see what this would look like
and give you something to test.

> Using a WQ_HIGHPRI workqueue helps, but it is still not RT (and won't
> meet future android requirements). It seems either workqueue needs to
> gain RT support, or drm_sched needs to support kthread_worker.

+Tejun to see if RT workqueue is in the plans.

>
> I know drm_sched switched from kthread_worker to workqueue for better
> scaling when xe was introduced. But if drm_sched can support either
> workqueue or kthread_worker during drm_sched_init, drivers can
> selectively use kthread_worker only for RT gpu queues. And because
> drivers require CAP_SYS_NICE for RT gpu queues, this should not cause
> scaling issues.
>

I don’t think having two paths will ever be acceptable, nor do I think
supporting a kthread would be all that easy. For example, in Xe we queue
additional work items outside of the scheduler on the queue for ordering
reasons — we’d have to move all of that code down into DRM sched or
completely redesign our submission model to avoid this. I’m not sure if
other drivers also do this, but it is allowed.

> Thoughts? Or perhaps this becomes less of an issue if all drm_sched
> users have concrete plans for userspace submissions..

Maybe some day....

Matt