On Mon, Mar 23, 2026 at 11:06:13AM +0100, Boris Brezillon wrote: > On Mon, 23 Mar 2026 00:58:51 -0700 > Matthew Brost <[email protected]> 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
