On Fri, Sep 23, 2016 at 03:49:26PM +0200, Daniel Vetter wrote: > On Mon, Aug 29, 2016 at 08:08:33AM +0100, Chris Wilson wrote: > > With the seqlock now extended to cover the lookup of the fence and its > > testing, we can perform that testing solely under the seqlock guard and > > avoid the effective locking and serialisation of acquiring a reference to > > the request. As the fence is RCU protected we know it cannot disappear > > as we test it, the same guarantee that made it safe to acquire the > > reference previously. The seqlock tests whether the fence was replaced > > as we are testing it telling us whether or not we can trust the result > > (if not, we just repeat the test until stable). > > > > Signed-off-by: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> > > Cc: Sumit Semwal <sumit.semwal@xxxxxxxxxx> > > Cc: linux-media@xxxxxxxxxxxxxxx > > Cc: dri-devel@xxxxxxxxxxxxxxxxxxxxx > > Cc: linaro-mm-sig@xxxxxxxxxxxxxxxx > > Not entirely sure this is safe for non-i915 drivers. We might now call > ->signalled on a zombie fence (i.e. refcount == 0, but not yet kfreed). > i915 can do that, but other drivers might go boom. All fences must be under RCU guard, or is that the sticking point? Given that, the problem is fence reallocation within the RCU grace period. If we can mandate that fence reallocation must be safe for concurrent fence->ops->*(), we can use this technique to avoid the serialisation barrier otherwise required. In the simple stress test, the difference is an order of magnitude, and test_signaled_rcu is often on a path where every memory barrier quickly adds up (at least for us). So is it just that you worry that others using SLAB_DESTROY_BY_RCU won't ensure their fence is safe during the reallocation? -Chris -- Chris Wilson, Intel Open Source Technology Centre _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
