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@xxxxxxxxxxxxxxxxxx> 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 _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
