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
-----邮件原件-----
发件人: Peter Zijlstra [mailto:[email protected]]
发送时间: 2018年11月30日 6:06
收件人: Waiman Long <[email protected]>
抄送: Will Deacon <[email protected]>; Yongji Xie <[email protected]>;
[email protected]; [email protected]; Xie,Yongji
<[email protected]>; Zhang,Yu(ACU-T1) <[email protected]>; Liu,Qi(ACU-T1)
<[email protected]>; Yuan,Linsi <[email protected]>; Ni,Xun
<[email protected]>; Li,Lin(ACU-T1) <[email protected]>; Davidlohr Bueso
<[email protected]>
主题: Re: [RFC] locking/rwsem: Avoid issuing wakeup before setting the reader
waiter to nil
On Thu, Nov 29, 2018 at 01:34:05PM -0500, Waiman Long wrote:
> That will certainly work for x86. However, I am not sure if that will
> be optimal for arm and powerpc.
smp_mb__before_atomic()
cmpxchg_relaxed()
works. Also see pv_kick_node()'s commit:
34d54f3d6917 ("locking/pvqspinlock: Relax cmpxchg's to improve performance on
some architectures")
you might know the author of that :-)
