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..
