On Fri, May 20, 2016 at 07:32:09PM +1000, Michael Ellerman wrote: > On Thu, 2016-05-19 at 08:00 -0700, Paul E. McKenney wrote: > > On Thu, May 19, 2016 at 04:41:17PM +0200, Peter Zijlstra wrote: > > > On Thu, May 19, 2016 at 07:22:52AM -0700, Paul E. McKenney wrote: > > > > Agreed, these sorts of instruction sequences make a lot of sense. > > > > Of course, if you stuff too many intructions and cache misses between > > > > the LL and the SC, the SC success probability starts dropping, but short > > > > seqeunces of non-memory-reference instructions like the above should be > > > > just fine. > > > > > > In fact, pretty much every single LL/SC arch I've looked at doesn't > > > allow _any_ loads or stores inside and will guarantee SC failure (or > > > worse) if you do. > > > > Last I know, PowerPC allowed memory-reference instructions inside, but > > the more of them you have, the less likely your reservation is to survive. > > But perhaps I missed some fine print somewhere. And in any case, > > omitting them is certainly better. > > There's nothing in the architecture AFAIK. > > Also I don't see anything to indicate that doing more unrelated accesses makes > the reservation more likely to be lost. Other than it causes you to hold the > reservation for longer, which increases the chance of some other CPU accessing > the variable. And also more likely to hit cache-geometry limitations. > Having said that, the architecture is written to provide maximum wiggle room > for implementations. So the list of things that may cause the reservation to be > lost includes "Implementation-specific characteristics of the coherence > mechanism", ie. anything. > > > > This immediately disqualifies things like calls/traps/etc.. because > > > those implicitly issue stores. > > > > Traps for sure. Not so sure about calls on PowerPC. > > Actually no, exceptions (aka interrupts/traps) are explicitly defined to *not* > clear the reservation. And function calls are just branches so should also be > fine. But don't most interrupt/trap handlers clear the reservation in software? 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
