Re: drm_sched run_job and scheduling latency

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

On Thu, 5 Mar 2026 01:10:06 -0800
Matthew Brost <matthew.brost@intel.com> wrote:

> I can't say I agree with either of you here.
> 
> In about an hour, I seemingly have a bypass path working in DRM sched +
> Xe, and my diff is:
> 
> 108 insertions(+), 31 deletions(-)

First of all, I'm not blindly rejecting the approach, see how I said
"I'm not thrilled" not "No way!". So yeah, if you have something to
propose, feel free to post the diff here or as an RFC on the ML.

Secondly, I keep thinking the fast-path approach doesn't quite fix
the problem at hand where we actually want queuing/dequeuing operations
to match the priority of the HW/FW context, because if your HW context
is high prio but you're struggling to fill the HW queue, it's not truly
high prio. Note that it's problem that was made more evident with FW
scheduling (and the 1:1 entity:sched association), before that we just
had one thread that was dequeuing from entities and pushing to HW
queues based on entities priorities, so priority was somehow better
enforced.

So yeah, even ignoring the discrepancy that might emerge from this new
fast-path-run_job (and the potential maintenance burden we mentioned),
saying "you'll get proper queueing/dequeuing priority enforcement only
if you have no deps, and the pipeline is not full" is kinda limited
IMHO. I'd rather we think about a solution that solves the entire
problem, which both the kthread_work[er] and workqueue(RT) proposals
do.