On Tue, Dec 05, 2017 at 11:33:39AM -0800, Paul E. McKenney wrote: > On Tue, Dec 05, 2017 at 09:24:21PM +0200, Michael S. Tsirkin wrote: > > On Tue, Dec 05, 2017 at 08:17:33PM +0100, Peter Zijlstra wrote: > > > On Tue, Dec 05, 2017 at 08:57:46PM +0200, Michael S. Tsirkin wrote: > > > > > > > I don't see WRITE_ONCE inserting any barriers, release or > > > > write. > > > > > > Correct, never claimed there was. > > > > > > Just saying that: > > > > > > obj = READ_ONCE(*foo); > > > val = READ_ONCE(obj->val); > > > > > > Never needs a barrier (except on Alpha and we want to make that go > > > away). Simply because a CPU needs to complete the load of @obj before it > > > can compute the address &obj->val. Thus the second load _must_ come > > > after the first load and we get LOAD-LOAD ordering. > > > > > > Alpha messing that up is a royal pain, and Alpha not being an > > > active/living architecture is just not worth the pain of keeping this in > > > the generic model. > > > > > > > Right. What I am saying is that for writes you need > > > > WRITE_ONCE(obj->val, 1); > > smp_wmb(); > > WRITE_ONCE(*foo, obj); > > I believe Peter was instead suggesting: > > WRITE_ONCE(obj->val, 1); > smp_store_release(foo, obj); Isn't that more expensive though? > > and this barrier is no longer paired with anything until > > you realize there's a dependency barrier within READ_ONCE. > > > > Barrier pairing was a useful tool to check code validity, > > maybe there are other, better tools now. > > There are quite a few people who say that smp_store_release() is > easier for the tools to analyze than is smp_wmb(). My experience with > smp_read_barrier_depends() and rcu_dereference() leads me to believe > that they are correct. > > Thanx, Paul OK, but smp_store_release is still not paired with anything since we rely on READ_ONCE to include the implicit dpendendency barrier. -- MST _______________________________________________ Virtualization mailing list Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/virtualization