On Mon, 2014-02-17 at 14:14 -0800, Paul E. McKenney wrote: > On Mon, Feb 17, 2014 at 09:39:54PM +0100, Richard Biener wrote: > > On February 17, 2014 7:18:15 PM GMT+01:00, "Paul E. McKenney" > > <paul...@linux.vnet.ibm.com> wrote: > > >On Wed, Feb 12, 2014 at 07:12:05PM +0100, Peter Zijlstra wrote: > > >> On Wed, Feb 12, 2014 at 09:42:09AM -0800, Paul E. McKenney wrote: > > >> > You need volatile semantics to force the compiler to ignore any > > >proofs > > >> > it might otherwise attempt to construct. Hence all the > > >ACCESS_ONCE() > > >> > calls in my email to Torvald. (Hopefully I translated your example > > >> > reasonably.) > > >> > > >> My brain gave out for today; but it did appear to have the right > > >> structure. > > > > > >I can relate. ;-) > > > > > >> I would prefer it C11 would not require the volatile casts. It should > > >> simply _never_ speculate with atomic writes, volatile or not. > > > > > >I agree with not needing volatiles to prevent speculated writes. > > >However, > > >they will sometimes be needed to prevent excessive load/store > > >combining. > > >The compiler doesn't have the runtime feedback mechanisms that the > > >hardware has, and thus will need help from the developer from time > > >to time. > > > > > >Or maybe the Linux kernel simply waits to transition to C11 relaxed > > >atomics > > >until the compiler has learned to be sufficiently conservative in its > > >load-store combining decisions. > > > > Sounds backwards. Currently the compiler does nothing to the atomics. I'm > > sure we'll eventually add something. But if testing coverage is zero > > outside then surely things get worse, not better with time. > > Perhaps we solve this chicken-and-egg problem by creating a test suite?
Perhaps. The test suite might also be a good set of examples showing which cases we expect to be optimized in a certain way, and which not. I suppose the uses of (the equivalent) of atomics in the kernel would be a good start. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
