On Fri, Sep 27, 2013 at 05:34:34PM +0200, Peter Zijlstra wrote: > On Fri, Sep 27, 2013 at 08:17:50AM -0700, Paul E. McKenney wrote: > > > Barriers are fundamentally about order; and order only makes sense if > > > there's more than 1 party to the game. > > > > Oddly enough, there is one exception that proves the rule... On Itanium, > > suppose we have the following code, with x initially equal to zero: > > > > CPU 1: ACCESS_ONCE(x) = 1; > > > > CPU 2: r1 = ACCESS_ONCE(x); r2 = ACCESS_ONCE(x); > > > > Itanium architects have told me that it really is possible for CPU 2 to > > see r1==1 and r2==0. Placing a memory barrier between CPU 2's pair of > > fetches prevents this, but without any other memory barrier to pair with. > > Oh man.. its really past time to sink that itanic already. > > I suppose it allows the cpu to reorder the reads in its pipeline and the > memory barrier disallows this. Curious.. does our memory-barriers.txt > file mention this 'fun' fact? Probably not. I was recently reminded of it by some people on the C++ standards committee. I had first heard of it about 5 years ago, but hadn't heard definitively until quite recently. I defer to the Itanium maintainers to actually make the required changes, should they choose to do so. I suppose that one way to handle it in the Linux kernel would be to make ACCESS_ONCE() be architecture specific, with Itanium placing a memory barrier either before or after --- either would work. But since Itanium seems to run Linux reliably, I am guessing that the probability of misordering is quite low. But again, the ball is firmly in the Itanium maintainers' courts, and I have added them on CC. 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>