Re: [RFC PATCH 02/12] drm/dep: Add DRM dependency queue layer

[Boris Brezillon]

On Mon, 23 Mar 2026 00:58:51 -0700
Matthew Brost <matthew.brost@xxxxxxxxx> wrote:

> > > It's not the refcount model I'm complaining about, it's the "part of it
> > > is always freed immediately, part of it is deferred, but not always ..."
> > > that happens in drm_dep_job_release() I'm questioning. I'd really
> > > prefer something like:
> > >   
> > 
> > You are completely missing the point here.
> >   
> 
> Let me rephrase this — I realize this may come across as rude, which is
> not my intent.

No offense taken ;-).

> I believe there is simply a disconnect in understanding
> the constraints.
> 
> In my example below, the job release completes within bounded time
> constraints, which makes it suitable for direct release in IRQ context,
> bypassing the need for a work item that would otherwise incur a costly
> CPU context switch.

In the other thread, I've explained in more details why I think
deferred cleanup of jobs is not as bad as you make it sound (context
switch amortized by the fact it's already there for queue progress
checking). But let's assume it is, I'd prefer a model where we say
"ops->job_release() has to be IRQ-safe" and have implementations defer
their cleanup if they have to, than this mixed approach with a flag. Of
course, I'd still like to have numbers proving that this job cleanup
deferral actually makes a difference in practice :P.