Re: [RFC PATCH 03/15] Provide atomic_t functions implemented with ISO-C++11 atomics

On Thu, May 19, 2016 at 10:52:19AM +0100, David Howells wrote: > Peter Zijlstra wrote: > > > Does this generate 'sane' code for LL/SC archs? That is, a single LL/SC > > loop and not a loop around an LL/SC cmpxchg. > > Depends on your definition of 'sane'. The code will

Re: [RFC PATCH 03/15] Provide atomic_t functions implemented with ISO-C++11 atomics

On Thu, May 19, 2016 at 10:52:19AM +0100, David Howells wrote: > Peter Zijlstra wrote: > > > Does this generate 'sane' code for LL/SC archs? That is, a single LL/SC > > loop and not a loop around an LL/SC cmpxchg. > > Depends on your definition of 'sane'. The code will work - but it's not >

Re: [RFC PATCH 03/15] Provide atomic_t functions implemented with ISO-C++11 atomics

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

Re: [RFC PATCH 03/15] Provide atomic_t functions implemented with ISO-C++11 atomics

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

Re: [RFC PATCH 03/15] Provide atomic_t functions implemented with ISO-C++11 atomics

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

Re: [RFC PATCH 03/15] Provide atomic_t functions implemented with ISO-C++11 atomics

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

Re: [RFC PATCH 03/15] Provide atomic_t functions implemented with ISO-C++11 atomics

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,

Re: [RFC PATCH 03/15] Provide atomic_t functions implemented with ISO-C++11 atomics

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,

Re: [RFC PATCH 03/15] Provide atomic_t functions implemented with ISO-C++11 atomics

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

Re: [RFC PATCH 03/15] Provide atomic_t functions implemented with ISO-C++11 atomics

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

Re: [RFC PATCH 03/15] Provide atomic_t functions implemented with ISO-C++11 atomics

On Thu, May 19, 2016 at 12:50:00PM +0200, Peter Zijlstra wrote: > On Thu, May 19, 2016 at 10:52:19AM +0100, David Howells wrote: > > Peter Zijlstra wrote: > > > > > Does this generate 'sane' code for LL/SC archs? That is, a single LL/SC > > > loop and not a loop around an

Re: [RFC PATCH 03/15] Provide atomic_t functions implemented with ISO-C++11 atomics

On Thu, May 19, 2016 at 12:50:00PM +0200, Peter Zijlstra wrote: > On Thu, May 19, 2016 at 10:52:19AM +0100, David Howells wrote: > > Peter Zijlstra wrote: > > > > > Does this generate 'sane' code for LL/SC archs? That is, a single LL/SC > > > loop and not a loop around an LL/SC cmpxchg. > > > I

Re: [RFC PATCH 03/15] Provide atomic_t functions implemented with ISO-C++11 atomics

On Thu, May 19, 2016 at 01:31:16PM +0200, Peter Zijlstra wrote: > Where the __special_marker__ marks the whole { } scope as being the > inside of LL/SC and all variables must be in registers before we start. > If the compiler is not able to guarantee this, it must generate a > compile time error

Re: [RFC PATCH 03/15] Provide atomic_t functions implemented with ISO-C++11 atomics

On Thu, May 19, 2016 at 01:31:16PM +0200, Peter Zijlstra wrote: > Where the __special_marker__ marks the whole { } scope as being the > inside of LL/SC and all variables must be in registers before we start. > If the compiler is not able to guarantee this, it must generate a > compile time error

Re: [RFC PATCH 03/15] Provide atomic_t functions implemented with ISO-C++11 atomics

On Thu, May 19, 2016 at 12:50:00PM +0200, Peter Zijlstra wrote: > > I suspect that might be quite a stretch. > > > > I've opened: > > > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71191 > > > > to cover this. > > Thanks; until such time as this stretch has been made I don't see this >

Re: [RFC PATCH 03/15] Provide atomic_t functions implemented with ISO-C++11 atomics

On Thu, May 19, 2016 at 12:50:00PM +0200, Peter Zijlstra wrote: > > I suspect that might be quite a stretch. > > > > I've opened: > > > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71191 > > > > to cover this. > > Thanks; until such time as this stretch has been made I don't see this >

Re: [RFC PATCH 03/15] Provide atomic_t functions implemented with ISO-C++11 atomics

On Thu, May 19, 2016 at 10:52:19AM +0100, David Howells wrote: > Peter Zijlstra wrote: > > > Does this generate 'sane' code for LL/SC archs? That is, a single LL/SC > > loop and not a loop around an LL/SC cmpxchg. > I think the code it generates should look something like:

Re: [RFC PATCH 03/15] Provide atomic_t functions implemented with ISO-C++11 atomics

On Thu, May 19, 2016 at 10:52:19AM +0100, David Howells wrote: > Peter Zijlstra wrote: > > > Does this generate 'sane' code for LL/SC archs? That is, a single LL/SC > > loop and not a loop around an LL/SC cmpxchg. > I think the code it generates should look something like: > >

Re: [RFC PATCH 03/15] Provide atomic_t functions implemented with ISO-C++11 atomics

Peter Zijlstra wrote: > Does this generate 'sane' code for LL/SC archs? That is, a single LL/SC > loop and not a loop around an LL/SC cmpxchg. Depends on your definition of 'sane'. The code will work - but it's not necessarily the most optimal. gcc currently keeps the

Re: [RFC PATCH 03/15] Provide atomic_t functions implemented with ISO-C++11 atomics

Peter Zijlstra wrote: > Does this generate 'sane' code for LL/SC archs? That is, a single LL/SC > loop and not a loop around an LL/SC cmpxchg. Depends on your definition of 'sane'. The code will work - but it's not necessarily the most optimal. gcc currently keeps the __atomic_load_n() and

Re: [RFC PATCH 03/15] Provide atomic_t functions implemented with ISO-C++11 atomics

On Thu, May 19, 2016 at 08:36:49AM +0100, David Woodhouse wrote: > On Wed, 2016-05-18 at 19:32 +0200, Peter Zijlstra wrote: > > > > Does this generate 'sane' code for LL/SC archs? That is, a single LL/SC > > loop and not a loop around an LL/SC cmpxchg. > > The whole point of using compiler

Re: [RFC PATCH 03/15] Provide atomic_t functions implemented with ISO-C++11 atomics

On Thu, May 19, 2016 at 08:36:49AM +0100, David Woodhouse wrote: > On Wed, 2016-05-18 at 19:32 +0200, Peter Zijlstra wrote: > > > > Does this generate 'sane' code for LL/SC archs? That is, a single LL/SC > > loop and not a loop around an LL/SC cmpxchg. > > The whole point of using compiler

Re: [RFC PATCH 03/15] Provide atomic_t functions implemented with ISO-C++11 atomics

On Wed, 2016-05-18 at 19:32 +0200, Peter Zijlstra wrote: > > Does this generate 'sane' code for LL/SC archs? That is, a single LL/SC > loop and not a loop around an LL/SC cmpxchg. The whole point of using compiler intrinsics and letting the compiler actually see what's going on... is that it

Re: [RFC PATCH 03/15] Provide atomic_t functions implemented with ISO-C++11 atomics

On Wed, 2016-05-18 at 19:32 +0200, Peter Zijlstra wrote: > > Does this generate 'sane' code for LL/SC archs? That is, a single LL/SC > loop and not a loop around an LL/SC cmpxchg. The whole point of using compiler intrinsics and letting the compiler actually see what's going on... is that it

Re: [RFC PATCH 03/15] Provide atomic_t functions implemented with ISO-C++11 atomics

On Wed, May 18, 2016 at 04:10:59PM +0100, David Howells wrote: > +/** > + * atomic_fetch_or - perform *v |= mask and return old value of *v > + * @v: pointer to atomic_t > + * @mask: mask to OR on the atomic_t > + */ > +static inline int atomic_fetch_or(atomic_t *v, int mask) > +{ > + return

Re: [RFC PATCH 03/15] Provide atomic_t functions implemented with ISO-C++11 atomics

On Wed, May 18, 2016 at 04:10:59PM +0100, David Howells wrote: > +/** > + * atomic_fetch_or - perform *v |= mask and return old value of *v > + * @v: pointer to atomic_t > + * @mask: mask to OR on the atomic_t > + */ > +static inline int atomic_fetch_or(atomic_t *v, int mask) > +{ > + return

Re: [RFC PATCH 03/15] Provide atomic_t functions implemented with ISO-C++11 atomics

On Wed, May 18, 2016 at 04:10:59PM +0100, David Howells wrote: > +/** > + * __atomic_add_unless - add unless the number is already a given value > + * @v: pointer of type atomic_t > + * @a: the amount to add to v... > + * @u: ...unless v is equal to u. > + * > + * Atomically adds @a to @v, so long

Re: [RFC PATCH 03/15] Provide atomic_t functions implemented with ISO-C++11 atomics

On Wed, May 18, 2016 at 04:10:59PM +0100, David Howells wrote: > +/** > + * __atomic_add_unless - add unless the number is already a given value > + * @v: pointer of type atomic_t > + * @a: the amount to add to v... > + * @u: ...unless v is equal to u. > + * > + * Atomically adds @a to @v, so long

Re: [RFC PATCH 03/15] Provide atomic_t functions implemented with ISO-C++11 atomics

On Wed, May 18, 2016 at 04:10:59PM +0100, David Howells wrote: > (b) An ISYNC instruction is emitted as the Acquire barrier with >__ATOMIC_SEQ_CST, but I'm not sure this is strong enough. > > (c) An LWSYNC instruction is emitted as the Release barrier with >

Re: [RFC PATCH 03/15] Provide atomic_t functions implemented with ISO-C++11 atomics

On Wed, May 18, 2016 at 04:10:59PM +0100, David Howells wrote: > (b) An ISYNC instruction is emitted as the Acquire barrier with >__ATOMIC_SEQ_CST, but I'm not sure this is strong enough. > > (c) An LWSYNC instruction is emitted as the Release barrier with >

[RFC PATCH 03/15] Provide atomic_t functions implemented with ISO-C++11 atomics

Provide an implementation of the atomic_t functions implemented with ISO-C++11 atomics. This has some advantages over using inline assembly: (1) The compiler has a much better idea of what is going on and can optimise appropriately, whereas with inline assembly, the content is an

[RFC PATCH 03/15] Provide atomic_t functions implemented with ISO-C++11 atomics

Provide an implementation of the atomic_t functions implemented with ISO-C++11 atomics. This has some advantages over using inline assembly: (1) The compiler has a much better idea of what is going on and can optimise appropriately, whereas with inline assembly, the content is an