On Mon, Oct 12, 2015 at 08:46:21AM +0200, Peter Zijlstra wrote:
> On Sun, Oct 11, 2015 at 06:25:20PM +0800, Boqun Feng wrote:
> > On Sat, Oct 10, 2015 at 09:58:05AM +0800, Boqun Feng wrote:
> > > Hi Peter,
> > >
> > > Sorry for replying late.
> > >
> > > On Thu, Oct 01, 2015 at 02:27:16PM +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")
> > >
> > > I probably didn't make myself clear here, my point is that if we use
> > > __atomic_op_acquire() to built *_cmpchg_acquire(For ARM and PowerPC),
> > > the barrier will be implied _unconditionally_, meaning no matter cmp
> > > fails or not, there will be a barrier after the cmpxchg operation.
> > > Therefore we have to use assembly to implement the operations right now.
>
> See later, but no, you don't _have_ to.
>
> > Or let me try another way to explain this. What I wanted to say here is
> > that unlike the implementation of xchg family, which needs only to
> > implement _relaxed version and *remove* the fully ordered version, the
> > implementation of cmpxchg family needs to *remain* the fully ordered
> > version and implement the _acquire version in assembly. Because if we
> > use __atomic_op_*(), the barriers in the cmpxchg family will be implied
> > *unconditionally*, for example:
>
> So the point that confused me, and which is still valid for the above,
> is your use of 'need'.
> Indeed, my apologies for confusing more.. > You don't need to omit the barrier at all. Its perfectly valid to issue > too many barriers (pointless and a waste of time, yes; incorrect, no). > Agreed. > So what you want to say is: "Optimize cmpxchg_acquire() to avoid > superfluous barrier". Yes. I would like to implement a cmpxchg_acquire that really has no barrier if cmp failed, which became my 'need' for the implementation. But you are right, we don't have to omit the barrier. I will modify the commit log to explain this clear in the next version. Thank you! Regards, Boqun
signature.asc
Description: PGP signature
_______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
