+Cc Tejun On Thu, 2026-07-02 at 15:37 +0100, Tvrtko Ursulin wrote: >
[…] > DRM scheduler was originally using kthreads but was converted workqueues due > desire by xe to create thousands of schedulers. This series also questions > whether that was needed, given how the submission is serialized by a device > global lock (per GT, so almost device global). Panthor has a similar > situation; > hence the series contains two patches to move those two to a setup which > matches > the design of those drivers. > > Other drivers, like for example amdgpu, v3d, etnaviv etc, which use the > scheduler as a hardware scheduler, where number of instances follow the number > of hardware blocks instead the number of userspace contexts, are completely > fine. > > There are use cases however which do currently track the number of userspace > contexts and which do allow for more parallelism. For those a straight > kthread_work conversion would be a problem due an explosion in number of > threads. > > The most direct example is panthor VM bind queue which creates a scheduler per > userspace context and relies on work queue concurrency management to keep the > number of threads in check. > > This creates a challenge for the kthread_work conversion. To solve which I for > now opted to create a trivial round-robin thread pool. For the RFC this is > limited to four CPU threads and is something which will need to be discussed. > Ie. how much parallelsim those really need. The true answer is somewhere > between > "at most the number of active userspace contexts and the number of CPU cores". > Or it could be less than that, since after all, VM BIND parallelism is > eventually going to choke on a narrower gate of actual GPU execution. We could > also allow drivers to pick their number. Anyone remember whether that was discussed back in the day of converting to workqueue? What makes this idea suspicious in my mind is that the workqueue implementation exists to solve precisely this issue: decide how many kthreads really need to be spawned. AFAIK it can spawn additional threads dynamically if necessary. So the first question I would like to see considered is whether workqueue could be improved in any way to address said latency issues. Have you already considered that, Tvrtko? IOW, is it the nature of workqueue or our way of using them in drm_sched which causes this performance difference in the submit path? It would seem that it's the desire for more fine-grained scheduling characteristic control that you get with a kthread. > > > […] > Tvrtko Ursulin (8): > drm/panthor: Remove redundant drm_sched_job_cleanup() from the > .free_job callback > drm/panthor: Use separate workqueue for DRM scheduler > drm/sched: Use generic naming for workqueue helpers This should be a separate patch :) P.
