[Intel-gfx] [PATCH] drm/i915: Do an optimistic is-busy? check first

[Chris Wilson]

On Thu, Sep 05, 2013 at 06:24:33PM +0200, Daniel Vetter wrote:
> On Thu, Sep 5, 2013 at 4:50 PM, Chris Wilson <chris at chris-wilson.co.uk> wrote:
> >> > +   /* Do an optimistic check for activity - we don't care about userspace
> >> > +    * racing with itself, that is always problematic.
> >> > +    */
> >> > +   ring = obj->ring;
> >> > +   if (ring && obj->last_read_seqno == ring->outstanding_lazy_seqno)
> >> > +           goto lock_and_flush;
> >>
> >> Feels a bit too tricky ... How useful is just an
> >>
> >>       if (ACCESS_ONCE(obj->active))
> >>               goto lock_and_flush;
> >
> > Not good enough, still ends up fighting for the lock.
> 
> Pondering this some more the problem is that I don't think we can
> ignore racing userspace since it can legitimately race here, e.g.
> - dri2 client uses the busy check to figure out whether it can access
> the frontbuffer for pixel readback
> - X server does a pageflip/blt which results in a ring switch
> 
> If now the ring we switch to is ahead of the old ring with signalling
> seqno completion and  the lockless busy reads the ring and seqno out
> of order we'll report the buffer falsely as non-busy. And the above
> scenario doesn't involve anything userspace shouldn't do.

It also a confusion that the kernel can't prevent.

lock_mutex
A checks bo, reports it idle
unlock_mutex

lock_mutex
B renders to bo
unlock_mutex

lock_mutex
A uses bo, stalls
unlock_mutex

Whether or not the checking of the bo is locked is irrelevant as it can
be gazzumped at anytime between the check and the use.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre