[adding parisc list]
On Fri, 2017-06-09 at 13:13 +0200, Peter Zijlstra wrote:
> On Fri, Jun 09, 2017 at 01:05:06PM +0200, Peter Zijlstra wrote:
>
> > The spinlock based atomics should be SC, that is, none of them
> > appear to
> > place extra barriers in atomic_cmpxchg() or any of the other SC
>
[adding parisc list]
On Fri, 2017-06-09 at 13:13 +0200, Peter Zijlstra wrote:
> On Fri, Jun 09, 2017 at 01:05:06PM +0200, Peter Zijlstra wrote:
>
> > The spinlock based atomics should be SC, that is, none of them
> > appear to
> > place extra barriers in atomic_cmpxchg() or any of the other SC
>
On Fri, Jun 09, 2017 at 10:28:50AM -0700, Vineet Gupta wrote:
> On 06/09/2017 04:13 AM, Peter Zijlstra wrote:
> > On Fri, Jun 09, 2017 at 01:05:06PM +0200, Peter Zijlstra wrote:
> >
> > > The spinlock based atomics should be SC, that is, none of them appear to
> > > place extra barriers in
On Fri, Jun 09, 2017 at 10:28:50AM -0700, Vineet Gupta wrote:
> On 06/09/2017 04:13 AM, Peter Zijlstra wrote:
> > On Fri, Jun 09, 2017 at 01:05:06PM +0200, Peter Zijlstra wrote:
> >
> > > The spinlock based atomics should be SC, that is, none of them appear to
> > > place extra barriers in
On 06/09/2017 04:13 AM, Peter Zijlstra wrote:
On Fri, Jun 09, 2017 at 01:05:06PM +0200, Peter Zijlstra wrote:
The spinlock based atomics should be SC, that is, none of them appear to
place extra barriers in atomic_cmpxchg() or any of the other SC atomic
primitives and therefore seem to rely on
On 06/09/2017 04:13 AM, Peter Zijlstra wrote:
On Fri, Jun 09, 2017 at 01:05:06PM +0200, Peter Zijlstra wrote:
The spinlock based atomics should be SC, that is, none of them appear to
place extra barriers in atomic_cmpxchg() or any of the other SC atomic
primitives and therefore seem to rely on
On 6/9/2017 7:05 AM, Peter Zijlstra wrote:
Subject: atomic: Fix atomic_set_release() for 'funny' architectures
Those architectures that have a special atomic_set implementation also
need a special atomic_set_release(), because for the very same reason
WRITE_ONCE() is broken for them,
On 6/9/2017 7:05 AM, Peter Zijlstra wrote:
Subject: atomic: Fix atomic_set_release() for 'funny' architectures
Those architectures that have a special atomic_set implementation also
need a special atomic_set_release(), because for the very same reason
WRITE_ONCE() is broken for them,
On Fri, Jun 09, 2017 at 01:05:06PM +0200, Peter Zijlstra wrote:
> The spinlock based atomics should be SC, that is, none of them appear to
> place extra barriers in atomic_cmpxchg() or any of the other SC atomic
> primitives and therefore seem to rely on their spinlock implementation
> being SC
On Fri, Jun 09, 2017 at 01:05:06PM +0200, Peter Zijlstra wrote:
> The spinlock based atomics should be SC, that is, none of them appear to
> place extra barriers in atomic_cmpxchg() or any of the other SC atomic
> primitives and therefore seem to rely on their spinlock implementation
> being SC
On Fri, Jun 09, 2017 at 11:24:50AM +0200, Peter Zijlstra wrote:
> +Non RmW ops:
> +
> +The non-RmW ops are (typically) regular LOADs and STOREs and are canonically
> +implemented using READ_ONCE(), WRITE_ONCE(), smp_load_acquire() and
> +smp_store_release() respectively.
> +
> +The one detail to
On Fri, Jun 09, 2017 at 11:24:50AM +0200, Peter Zijlstra wrote:
> +Non RmW ops:
> +
> +The non-RmW ops are (typically) regular LOADs and STOREs and are canonically
> +implemented using READ_ONCE(), WRITE_ONCE(), smp_load_acquire() and
> +smp_store_release() respectively.
> +
> +The one detail to
12 matches
Mail list logo
