On Fri, Nov 22, 2013 at 07:51:07PM +0100, Peter Zijlstra wrote: > On Fri, Nov 22, 2013 at 10:26:32AM -0800, Paul E. McKenney wrote: > > The real source of my cognitive pain is that here we have a sequence of > > code that has neither atomic instructions or memory-barrier instructions, > > but it looks like it still manages to act as a full memory barrier. > > Still not quite sure I should trust it... > > Yes, this is something that puzzles me too. > > That said, the two rules that: > > 1) stores aren't re-ordered against other stores > 2) reads aren't re-ordered against other reads > > Do make that: > > STORE x > LOAD x > > form a fence that neither stores nor loads can pass through from > either side; note however that they themselves rely on the data > dependency to not reorder against themselves. > > If you put them the other way around: > > LOAD x > STORE y > > we seem to get a stronger variant because stores are not re-ordered > against older reads. > > There is however the exception cause for rule 1) above, which includes > clflush, non-temporal stores and string ops; the actual mfence > instruction doesn't seem to have this exception and would thus be > slightly stronger still. > > Still confusion situation all round. At some point, we need people from Intel and AMD to look at it. Thanx, Paul -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>