On Mon, Jul 13, 2015 at 06:50:29PM +0100, Will Deacon wrote: > On Mon, Jul 13, 2015 at 04:54:47PM +0100, Peter Zijlstra wrote: > > However I think we should look at the insides of the critical sections; > > for example (from Documentation/memory-barriers.txt): > > > > " *A = a; > > RELEASE M > > ACQUIRE N > > *B = b; > > > > could occur as: > > > > ACQUIRE N, STORE *B, STORE *A, RELEASE M" > > > > This could not in fact happen, even though we could flip M and N, A and > > B will remain strongly ordered. > > > > That said, I don't think this could even happen on PPC because we have > > load_acquire and store_release, this means that: > > > > *A = a > > lwsync > > store_release M > > load_acquire N > > lwsync > > *B = b > > > > And since the store to M is wrapped inside two lwsync there must be > > strong store order, and because the load from N is equally wrapped in > > two lwsyncs there must also be strong load order. > > > > In fact, no store/load can cross from before the first lwsync to after > > the latter and the other way around. > > > > So in that respect it does provide full load-store ordering. What it > > does not provide is order for M and N, nor does it provide transitivity, > > but looking at our documentation I'm not at all sure we guarantee that > > in any case. > > So if I'm following along, smp_mb__after_unlock_lock *does* provide > transitivity when used with UNLOCK + LOCK, which is stronger than your > example here. Yes, that is indeed the intent. > I don't think we want to make the same guarantee for general RELEASE + > ACQUIRE, because we'd end up forcing most architectures to implement the > expensive macro for a case that currently has no users. Agreed, smp_mb__after_unlock_lock() makes a limited guarantee. > In which case, it boils down to the question of how expensive it would > be to implement an SC UNLOCK operation on PowerPC and whether that justifies > the existence of a complicated barrier macro that isn't used outside of > RCU. Given that it is either smp_mb() or nothing, I am not seeing the "complicated" part... Thanx, Paul -- To unsubscribe from this list: send the line "unsubscribe linux-arch" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
