Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1237371 > unrolled thread
| Started by | Peter Zijlstra <peterz@infradead.org> |
|---|---|
| First post | 2015-10-01 14:30 +0200 |
| Last post | 2015-10-01 17:20 +0200 |
| Articles | 5 — 2 participants |
Back to article view | Back to linux.kernel
This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by
below is the oldest one visible, not the original post.
Re: [RFC v2 5/7] powerpc: atomic: Implement cmpxchg{,64}_* and atomic{,64}_cmpxchg_* variants Peter Zijlstra <peterz@infradead.org> - 2015-10-01 14:30 +0200
Re: [RFC v2 5/7] powerpc: atomic: Implement cmpxchg{,64}_* and atomic{,64}_cmpxchg_* variants Peter Zijlstra <peterz@infradead.org> - 2015-10-01 14:40 +0200
Re: [RFC v2 5/7] powerpc: atomic: Implement cmpxchg{,64}_* and atomic{,64}_cmpxchg_* variants "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2015-10-01 17:20 +0200
Re: [RFC v2 5/7] powerpc: atomic: Implement cmpxchg{,64}_* and atomic{,64}_cmpxchg_* variants Peter Zijlstra <peterz@infradead.org> - 2015-10-01 19:20 +0200
Re: [RFC v2 5/7] powerpc: atomic: Implement cmpxchg{,64}_* and atomic{,64}_cmpxchg_* variants "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2015-10-01 17:20 +0200
| From | Peter Zijlstra <peterz@infradead.org> |
|---|---|
| Date | 2015-10-01 14:30 +0200 |
| Subject | Re: [RFC v2 5/7] powerpc: atomic: Implement cmpxchg{,64}_* and atomic{,64}_cmpxchg_* variants |
| Message-ID | <qeL9M-3Vj-11@gated-at.bofh.it> |
On Wed, Sep 16, 2015 at 11:49:33PM +0800, Boqun Feng wrote:
> Unlike other atomic operation variants, cmpxchg{,64}_acquire and
> atomic{,64}_cmpxchg_acquire don't have acquire semantics if the cmp part
> fails, so we need to implement these using assembly.
I think that is actually expected and documented. That is, a cmpxchg
only implies barriers on success. See:
ed2de9f74ecb ("locking/Documentation: Clarify failed cmpxchg() memory ordering semantics")
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[toc] | [next] | [standalone]
| From | Peter Zijlstra <peterz@infradead.org> |
|---|---|
| Date | 2015-10-01 14:40 +0200 |
| Message-ID | <qeLjs-46x-17@gated-at.bofh.it> |
| In reply to | #1237371 |
On Thu, Oct 01, 2015 at 02:27:15PM +0200, Peter Zijlstra wrote:
> On Wed, Sep 16, 2015 at 11:49:33PM +0800, Boqun Feng wrote:
> > Unlike other atomic operation variants, cmpxchg{,64}_acquire and
> > atomic{,64}_cmpxchg_acquire don't have acquire semantics if the cmp part
> > fails, so we need to implement these using assembly.
>
> I think that is actually expected and documented. That is, a cmpxchg
> only implies barriers on success. See:
>
> ed2de9f74ecb ("locking/Documentation: Clarify failed cmpxchg() memory ordering semantics")
Also:
654672d4ba1a6 (Will Deacon 2015-08-06 17:54:37 +0100 28) * store portion of the operation. Note that a failed cmpxchg_acquire
654672d4ba1a6 (Will Deacon 2015-08-06 17:54:37 +0100 29) * does -not- imply any memory ordering constraints.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> |
|---|---|
| Date | 2015-10-01 17:20 +0200 |
| Message-ID | <qeNOj-8mD-25@gated-at.bofh.it> |
| In reply to | #1237382 |
On Thu, Oct 01, 2015 at 02:36:26PM +0200, Peter Zijlstra wrote:
> On Thu, Oct 01, 2015 at 02:27:15PM +0200, Peter Zijlstra wrote:
> > On Wed, Sep 16, 2015 at 11:49:33PM +0800, Boqun Feng wrote:
> > > Unlike other atomic operation variants, cmpxchg{,64}_acquire and
> > > atomic{,64}_cmpxchg_acquire don't have acquire semantics if the cmp part
> > > fails, so we need to implement these using assembly.
> >
> > I think that is actually expected and documented. That is, a cmpxchg
> > only implies barriers on success. See:
> >
> > ed2de9f74ecb ("locking/Documentation: Clarify failed cmpxchg() memory ordering semantics")
>
> Also:
>
> 654672d4ba1a6 (Will Deacon 2015-08-06 17:54:37 +0100 28) * store portion of the operation. Note that a failed cmpxchg_acquire
> 654672d4ba1a6 (Will Deacon 2015-08-06 17:54:37 +0100 29) * does -not- imply any memory ordering constraints.
What C11 does is to allow the developer to specify different orderings
on success and failure. But it is no harder to supply a barrier (if
needed) on the failure path, right?
Thanx, Paul
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | Peter Zijlstra <peterz@infradead.org> |
|---|---|
| Date | 2015-10-01 19:20 +0200 |
| Message-ID | <qePGr-2Bk-41@gated-at.bofh.it> |
| In reply to | #1237501 |
On Thu, Oct 01, 2015 at 08:12:19AM -0700, Paul E. McKenney wrote: > What C11 does is to allow the developer to specify different orderings > on success and failure. But it is no harder to supply a barrier (if > needed) on the failure path, right? Quite right. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> |
|---|---|
| Date | 2015-10-01 17:20 +0200 |
| Message-ID | <qeNOj-8mD-31@gated-at.bofh.it> |
| In reply to | #1237382 |
On Thu, Oct 01, 2015 at 02:36:26PM +0200, Peter Zijlstra wrote:
> On Thu, Oct 01, 2015 at 02:27:15PM +0200, Peter Zijlstra wrote:
> > On Wed, Sep 16, 2015 at 11:49:33PM +0800, Boqun Feng wrote:
> > > Unlike other atomic operation variants, cmpxchg{,64}_acquire and
> > > atomic{,64}_cmpxchg_acquire don't have acquire semantics if the cmp part
> > > fails, so we need to implement these using assembly.
> >
> > I think that is actually expected and documented. That is, a cmpxchg
> > only implies barriers on success. See:
> >
> > ed2de9f74ecb ("locking/Documentation: Clarify failed cmpxchg() memory ordering semantics")
>
> Also:
>
> 654672d4ba1a6 (Will Deacon 2015-08-06 17:54:37 +0100 28) * store portion of the operation. Note that a failed cmpxchg_acquire
> 654672d4ba1a6 (Will Deacon 2015-08-06 17:54:37 +0100 29) * does -not- imply any memory ordering constraints.
Agreed, no need for ordering on failed cmpxchg.
Thanx, Paul
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [standalone]
Back to top | Article view | linux.kernel
csiph-web