From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751878AbdIRHwM (ORCPT ); Mon, 18 Sep 2017 03:52:12 -0400 Received: from mail-pg0-f52.google.com ([74.125.83.52]:46596 "EHLO mail-pg0-f52.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750772AbdIRHwL (ORCPT ); Mon, 18 Sep 2017 03:52:11 -0400 X-Google-Smtp-Source: AOwi7QDqBbE6CyRRR0IQsvHUSJB8/Jjy/ObG4FJ6NFZiTB38EK8wzSkYMalzq7fzK5vwZPv0s63Lcw== Date: Mon, 18 Sep 2017 15:52:42 +0800 From: Boqun Feng To: "Paul E. McKenney" Cc: j.alglave@ucl.ac.uk, luc.maranget@inria.fr, parri.andrea@gmail.com, stern@rowland.harvard.edu, dhowells@redhat.com, peterz@infradead.org, will.deacon@arm.com, npiggin@gmail.com, linux-kernel@vger.kernel.org Subject: Re: Memory-ordering recipes Message-ID: <20170918015353.GA15440@tardis> References: <20170917230509.GA21394@linux.vnet.ibm.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="BwCQnh7xodEAoBMC" Content-Disposition: inline In-Reply-To: <20170917230509.GA21394@linux.vnet.ibm.com> User-Agent: Mutt/1.8.3 (2017-05-23) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --BwCQnh7xodEAoBMC Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Sep 17, 2017 at 04:05:09PM -0700, Paul E. McKenney wrote: > Hello! >=20 Hi Paul, > The topic of memory-ordering recipes came up at the Linux Plumbers > Conference microconference on Friday, so I thought that I should summarize > what is currently "out there": >=20 > 1. memory-barriers.txt: A bit rambling and diffuse for a recipes > document. >=20 > 2. https://www.kernel.org/pub/linux/kernel/people/paulmck/LWNLinuxMM/Exam= ples.html > Many of the examples are on-point, but this is aimed more > at understanding the memory model than at an organized set > of recipes. >=20 > 3. https://www.kernel.org/pub/linux/kernel/people/paulmck/LWNLinuxMM/Exam= ples.html Duplicate links ;-) This should a link to some slides? > Slides 15-20. Again, some of the litmus tests are on-point, > but the focus is more on understanding the memory model than on > an organized set of recipes. >=20 > So what litmus tests are needed? Here is my initial set: >=20 > 1. Release-acquire chains, AKA ISA2, Z6.2, LB, and 3.LB >=20 > Lots of variety here, can in some cases substitute: > =09 > a. READ_ONCE() for smp_load_acquire() > b. WRITE_ONCE() for smp_store_release() > c. Dependencies for both smp_load_acquire() and > smp_store_release(). > d. smp_wmb() for smp_store_release() in first thread > of ISA2 and Z6.2. > e. smp_rmb() for smp_load_acquire() in last thread of ISA2. >=20 > 2. MP (see test6.pdf for nickname translation) >=20 > a. smp_store_release() / smp_load_acquire() > b. rcu_assign_pointer() / rcu_dereference() > c. smp_wmb() / smp_rmb() > d. Replacing either of the above with smp_mb() >=20 > 3. SB >=20 > a. smp_mb(), as in lockless wait-wakeup coordination. > And as in sys_membarrier()-scheduler coordination, > for that matter. b. replace smp_mb() with smp_mb__before_atomic() followed by a _relaxed cmpchg? As in pv_kick_node(): https://marc.info/?l=3Dlinux-kernel&m=3D150274124711012 Besides, do we also want to add Co* into the set? I think there may be some people still confused to think per-loc SC is not held, and they may add unnecessary barriers in their code. Those (Co*) recipes could serve as a guide for state-machine style programming. Thoughts? Regards, Boqun >=20 > Others? >=20 > Thanx, Paul >=20 --BwCQnh7xodEAoBMC Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAABCAAdFiEEj5IosQTPz8XU1wRHSXnow7UH+rgFAlm/e0cACgkQSXnow7UH +rjjPQgAswhKD168SjBjEHqoGgZdPq5zq1JDq4F6XI47zEglglao9e6JleQpj62g YNPsMZHxc4+64ye5FFeHi7f1dfXOoVOfS5N4QW2CTvGwa6CCuNBLVo9D9lcW/siF Ce4aHPbKaYP6LHPfYRVzJd8I430WgmSV0KVWCrRkuvqxX22aPOxjgDstbjPB1Wvx FsGrUn8/pLstCC844/d/GiwsUshkbLD3g18mHP8dxfPtJZvRCqSat7Zhd/vOF+bZ gc6b4qJdnaZNf+2WwnOB7jXoM+lhadG0jxPv4xOYl55GNZUm5m+8F/zHFyQsj3rm D4gjtDwDczwmU/kE2F97IR9xeXODaQ== =Lfnf -----END PGP SIGNATURE----- --BwCQnh7xodEAoBMC--