Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Fri, 30 Nov 2018 15:15:44 +0100
From:   Peter Zijlstra <peterz@infradead.org>
To:     "Liu,Qi(ACU-T1)" <liuqi16@baidu.com>
Cc:     Waiman Long <longman@redhat.com>,
        Will Deacon <will.deacon@arm.com>,
        Yongji Xie <elohimes@gmail.com>,
        "mingo@redhat.com" <mingo@redhat.com>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "Xie,Yongji" <xieyongji@baidu.com>,
        "Zhang,Yu(ACU-T1)" <zhangyu31@baidu.com>,
        "Yuan,Linsi" <yuanlinsi01@baidu.com>, "Ni,Xun" <nixun@baidu.com>,
        "Li,Lin(ACU-T1)" <lilin24@baidu.com>,
        Davidlohr Bueso <dave@stgolabs.net>
Subject: Re: =?utf-8?B?562U5aSNOiBbUkZDXSBsb2NraW5n?=
 =?utf-8?Q?=2Frwsem=3A_Avoi?= =?utf-8?Q?d?= issuing wakeup before setting the
 reader waiter to nil
Message-ID: <20181130141544.GK11632@hirez.programming.kicks-ass.net>
References: <5598cd71-c3c8-d6ef-eb30-777cf901a2ef@redhat.com>
 <20181129160627.GU2131@hirez.programming.kicks-ass.net>
 <8cc45695-b325-a219-8b46-d5da6ddfdd63@redhat.com>
 <20181129172700.GA11632@hirez.programming.kicks-ass.net>
 <20181129180828.GA11650@hirez.programming.kicks-ass.net>
 <729ceddb-dd9a-ec2a-f74e-03fa4d7e65e8@redhat.com>
 <20181129183103.GA4952@arm.com>
 <f991af45-2131-ad75-94cd-2c8548266a9e@redhat.com>
 <20181129220544.GE11632@hirez.programming.kicks-ass.net>
 <c1c9d6b30d7745ea9ac5b752f9a506c3@baidu.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <c1c9d6b30d7745ea9ac5b752f9a506c3@baidu.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Fri, Nov 30, 2018 at 09:34:19AM +0000, Liu,Qi(ACU-T1) wrote:
> Is there a semantic divergence between x86 instruction "LOCK cmpxchg"
> and the macro cmpxchg defined in linux kernel? The former guarantee
> full barrier in any case, and the latter only imply barrier in case of
> success?

> So, we use 	
>     smp_mb__before_atomic()
> 	cmpxchg_relaxed()  // no barrier
> to get rid of the redundant barrier
>    smp_mb__before_atomic()
>    cmpxchg()          // imply a redundant barrier when successing  

No, it is all horribly more complicated :-)

On x86: cmpxchg_relaxed() == cmpxchg() == LOCK CMPXCHG, however
smp_mb__{before,after}_atomic() is a no-op.

On say arm OTOH: cmpxchg_relaxed() == LL/SC, but then
smp_mb__{before,after}_atomic() is smp_mb(), such that: cmpxchg() := {
smp_mb__before_atomic(); cmpxchg_relaxed(); smp_mb__after_atomic(); }

The difference is that on x86 atomic instructions unconditionally imply
memory ordering; whereas on ARM they do not.