On Mon, Aug 22, 2016 at 10:55:22AM +0200, Daniel Vetter wrote: > This issue here is (I think) purely theoretical, since a compiler > would need to be especially foolish to recompute the value of > i915_gem_request_completed right after it was already used. Hence the > additional barrier() is also not really a restriction. > > But I believe this to be at least permissible, and since our rcu > trickery is a beast it's worth to annotate all the corner cases. > Chris proposed to instead just wrap a READ_ONCE around > request->fence.seqno in i915_gem_request_completed. But that has a > measurable impact on code size, and everywhere we hold a full > reference to the underlying request it's also not needed. And > personally I'd like to have just enough barriers and locking needed > for correctness, but not more - it makes it much easier in the future > to understand what's going on. > > Since the busy ioctl has now fully embraced it's races there's no > point annotating it there too. We really only need it in > active_get_rcu, since that function _must_ deliver a correct snapshot > of the active fences (and not chase something else). > > v2: Polish the comment a bit more (Chris). > > Cc: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> > Cc: Joonas Lahtinen <joonas.lahtinen@xxxxxxxxxxxxxxx> > Reviewed-by: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> > Signed-off-by: Daniel Vetter <daniel.vetter@xxxxxxxxx> Just the fun of the role reversal, I've pushed it. -Chris -- Chris Wilson, Intel Open Source Technology Centre _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
