From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752625AbbH1OQR (ORCPT ); Fri, 28 Aug 2015 10:16:17 -0400 Received: from mail-ig0-f179.google.com ([209.85.213.179]:33226 "EHLO mail-ig0-f179.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752106AbbH1OQP (ORCPT ); Fri, 28 Aug 2015 10:16:15 -0400 Date: Fri, 28 Aug 2015 22:16:02 +0800 From: Boqun Feng To: Peter Zijlstra Cc: linux-kernel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, Ingo Molnar , Benjamin Herrenschmidt , Paul Mackerras , Michael Ellerman , Thomas Gleixner , Will Deacon , "Paul E. McKenney" , Waiman Long Subject: Re: [RFC 3/5] powerpc: atomic: implement atomic{,64}_{add,sub}_return_* variants Message-ID: <20150828141602.GA924@fixme-laptop.cn.ibm.com> References: <1440730099-29133-1-git-send-email-boqun.feng@gmail.com> <1440730099-29133-4-git-send-email-boqun.feng@gmail.com> <20150828104854.GB16853@twins.programming.kicks-ass.net> <20150828120614.GC29325@fixme-laptop.cn.ibm.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="HcAYCG3uE/tztfnV" Content-Disposition: inline In-Reply-To: <20150828120614.GC29325@fixme-laptop.cn.ibm.com> User-Agent: Mutt/1.5.23+102 (2ca89bed6448) (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --HcAYCG3uE/tztfnV Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Aug 28, 2015 at 08:06:14PM +0800, Boqun Feng wrote: > Hi Peter, >=20 > On Fri, Aug 28, 2015 at 12:48:54PM +0200, Peter Zijlstra wrote: > > On Fri, Aug 28, 2015 at 10:48:17AM +0800, Boqun Feng wrote: > > > +/* > > > + * Since {add,sub}_return_relaxed and xchg_relaxed are implemented w= ith > > > + * a "bne-" instruction at the end, so an isync is enough as a acqui= re barrier > > > + * on the platform without lwsync. > > > + */ > > > +#ifdef CONFIG_SMP > > > +#define smp_acquire_barrier__after_atomic() \ > > > + __asm__ __volatile__(PPC_ACQUIRE_BARRIER : : : "memory") > > > +#else > > > +#define smp_acquire_barrier__after_atomic() barrier() > > > +#endif > > > +#define arch_atomic_op_acquire(op, args...) \ > > > +({ \ > > > + typeof(op##_relaxed(args)) __ret =3D op##_relaxed(args); \ > > > + smp_acquire_barrier__after_atomic(); \ > > > + __ret; \ > > > +}) > > > + > > > +#define arch_atomic_op_release(op, args...) \ > > > +({ \ > > > + smp_lwsync(); \ > > > + op##_relaxed(args); \ > > > +}) > >=20 > > Urgh, so this is RCpc. We were trying to get rid of that if possible. > > Lets wait until that's settled before introducing more of it. > >=20 > > lkml.kernel.org/r/20150820155604.GB24100@arm.com >=20 > OK, get it. Thanks. >=20 > So I'm not going to introduce these arch specific macros, I think what I > need to implement are just _relaxed variants and cmpxchg_acquire. Ah.. just read through the thread you mentioned, I might misunderstand you, probably because I didn't understand RCpc well.. You are saying that in a RELEASE we -might- switch from smp_lwsync() to smp_mb() semantically, right? I guess this means we -might- switch from RCpc to RCsc, right? If so, I think I'd better to wait until we have a conclusion for this. Thank you for your comments! Regards, Boqun --HcAYCG3uE/tztfnV Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAABCAAGBQJV4G0aAAoJEEl56MO1B/q4z8gH+wf+2DtwQucFd4TakApcbvS4 JdQEzM+oL61R0Wz68qd2oOHnKbeBHKKfLfcifVStG/31LA4t6y89/+SJsUKhvwIc TQOjIOSXD1m8TnP7aiaOUKyfC8joYB9BPKWUZl4u9sA3g1ln0gTdwEbefE2/BJZt TlDTNu3DPplUEdbHgKOIzYHAGgSS84QQ1lFDMuSqj3gbm8zgjNP5JyQsw8uXCpR1 LQJCu5hzmPuhT8hd/SO/x9dJ4UZaIm+cAmwBG//j13c6CmtWMtewaYehrYvtOQkx DnpS+fyC6OmQIvBtcUDCaBE8WzWsgC/GlRrkcuWxjBHBeZbEHpW0l+hynRUnQt8= =uGtb -----END PGP SIGNATURE----- --HcAYCG3uE/tztfnV--