[Intel-gfx] [PATCH] drm/i915: Don't disable interrupts independently of the lock

Chris Wilson chris at chris-wilson.co.uk
Thu Oct 10 20:30:35 UTC 2019


Quoting Sebastian Andrzej Siewior (2019-10-10 19:26:10)
> On 2019-10-10 19:11:27 [+0100], Chris Wilson wrote:
> > > --- a/drivers/gpu/drm/i915/i915_request.c
> > > +++ b/drivers/gpu/drm/i915/i915_request.c
> > > @@ -251,15 +251,13 @@ static bool i915_request_retire(struct i
> > >                 active->retire(active, rq);
> > >         }
> > >  
> > > -       local_irq_disable();
> > > -
> > >         /*
> > >          * We only loosely track inflight requests across preemption,
> > >          * and so we may find ourselves attempting to retire a _completed_
> > >          * request that we have removed from the HW and put back on a run
> > >          * queue.
> > >          */
> > > -       spin_lock(&rq->engine->active.lock);
> > > +       spin_lock_irq(&rq->engine->active.lock);
> > >         list_del(&rq->sched.link);
> > >         spin_unlock(&rq->engine->active.lock);
> > >  
> > > @@ -278,9 +276,7 @@ static bool i915_request_retire(struct i
> > >                 __notify_execute_cb(rq);
> > >         }
> > >         GEM_BUG_ON(!list_empty(&rq->execute_cb));
> > > -       spin_unlock(&rq->lock);
> > > -
> > > -       local_irq_enable();
> > > +       spin_unlock_irq(&rq->lock);
> > 
> > Nothing screams about the imbalance? irq off from one lock to the other?
> 
> There is no imbalance, is there? Interrupts are disabled as part of
> acquiring the first lock and enabled again as part of releasing the
> second lock.
> It may not look beautiful. 

Sure, it's at the same scope, I just expect at some point lockdep to
complain :)
 
> I'm just not sure if this
> 
> |         spin_lock_irq(&rq->engine->active.lock);
> |         list_del(&rq->sched.link);
> |         spin_unlock_irq(&rq->engine->active.lock);
> | 
> |         spin_lock_irq(&rq->lock);
> |         i915_request_mark_complete(rq);
>> |         spin_unlock_irq(&rq->lock);
> 
> has been avoided because an interrupt here could change something or if
> this is just an optimisation.

Just avoiding the back-to-back enable/disable.
-Chris


More information about the Intel-gfx mailing list