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

[Matthew Brost <matthew.brost@intel.com>]

On Mon, Mar 23, 2026 at 11:06:13AM +0100, Boris Brezillon wrote:
> On Mon, 23 Mar 2026 00:58:51 -0700
> Matthew Brost <matthew.brost@intel.com> 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.

Yes, I replied there will either drop this or have solid numbers showing
yes, the CPU utlization shows this is worth while.

Matt