Re: [PATCH 2/2] drm/i915: Protect engine request list with spinlock

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Feb 19, 2015 at 04:41:12PM +0000, Chris Wilson wrote:
> On Thu, Feb 19, 2015 at 06:18:55PM +0200, Mika Kuoppala wrote:
> > There are multiple players interested in the ring->request_list
> > state. Request submission can happen in kernel or user context,
> > idle worker is going through request list to free items. And then there
> > is hangcheck worker which tries to figure out if particular ring is
> > healthy by peeking at the request list among other things. And if
> > judged stuck by hangcheck, error state is colleted. Which in turns
> > needs access to ring->request_list.
> 
> We have discussed this before. Hangcheck does not need the lock so long
> as it is serialised with deletion. List processing with hangcheck during
> concurrent addition is safe.
> 
> For example, I expect the request locking to look like
> 
> http://cgit.freedesktop.org/~ickle/linux-2.6/tree/drivers/gpu/drm/i915/i915_gem_request.c#n691

I think longer-term with per-engine reset and fun stuff like that we
probably want the spinlock, just to avoid too many headaches with locking
auditing. For the execbuf fastpath it should just be one more spinlock per
ioctl, so hopefully bearable.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/intel-gfx





[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]
  Powered by Linux