Re: drm_sched run_job and scheduling latency

Tvrtko Ursulin
2026-03-05T08:35:37Z

On 04/03/2026 22:51, 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.
>
> 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.
>
> I know drm_sched switched from kthread_worker to workqueue for better

From a plain kthread actually. Anyway, I suggested trying the
kthread_worker approach a few times in the past but never got round
implementing it. Not dual paths but simply replacing the workqueues with
kthread_workers.

What is your thinking regarding how would the priority be configured? In
terms of the default and mechanism to select a higher priority
scheduling class.

Regards,

Tvrtko

> 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.
>
> Thoughts? Or perhaps this becomes less of an issue if all drm_sched
> users have concrete plans for userspace submissions..