Re: [RFC 2/8] drm/panthor: Use separate workqueue for DRM scheduler

[Boris Brezillon <boris.brezillon@collabora.com>]

On Thu, 9 Jul 2026 15:33:01 +0100
Tvrtko Ursulin <tvrtko.ursulin@igalia.com> wrote:

> >> But in principle I am fine with going with N workers. It's just a matter
> >> of what is N derived from and how big it is. It could be even be passed
> >> to alloc_workqueue in the today's code base but I accept there is not
> >> much value to that since I don't think there are SoC's with a Mali GPU
> >> and server level number of CPU cores.  
> > 
> > I think we can start with one ordered-wq per prio level. So basically
> > what you intended to do in this patch, but instead of having a single
> > ordered-wq, we have four of them (one per prio). It doesn't address the
> > fact run_job() on non-resident groups might hit their ringbuf before
> > resident ones, but that's probably good enough as a first step, and as
> > you pointed out, the current locking forces this serialization with no
> > more guarantee regarding who's going to be served first anyway, so it
> > can't be worse than it already is.  
> 
> Lets for a moment assume the kthread_worker idea will not fly due to xe, 
> or any other reason really. Also since the option for RT workqueues is 
> unexpectedly on the table. In that case, and assuming RT workqueues will 
> happen, could a feasible plan for panthor be to create three workqueues:
> 
>   1. One unbound with max_active = 2 for low and medium group priority.
>   2. Another unbound + WQ_HIGHPRI, also with max_active = 2 for high.
>   3. And one unbound + WQ_REALTIME, again max_active = 2 for realtime.
> 
> For high and realtime max_active either 2 or 1 on dual core, if there 
> are such SoCs. Two threads ensure same priority clients are able to keep 
> the GPU fed.
> 
> One issue is that you mentioned you would like dynamic priority changes 
> and with this it may be tricky. But ignoring that for the moment, and 
> the discussion on how to handle other panthor workers which take part in 
> the execution flow post submit, this should pretty much address the 
> submit latency from userspace to ->run_job(). What do you think, is it 
> worth entertaining this alternative?

I think that would do, yes.