On Thu, 9 Jul 2026 15:33:01 +0100 Tvrtko Ursulin <[email protected]> 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.
