From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751053AbdISCAJ (ORCPT ); Mon, 18 Sep 2017 22:00:09 -0400 Received: from mail-pg0-f49.google.com ([74.125.83.49]:56405 "EHLO mail-pg0-f49.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750862AbdISCAI (ORCPT ); Mon, 18 Sep 2017 22:00:08 -0400 X-Google-Smtp-Source: AOwi7QBsnnb3mlybk/EQ/gdx2s1OuMQ1fjbOwTCbh/JV38WeATFkhJm3yHIdko8aeW9X1lihxoQWfg== Date: Tue, 19 Sep 2017 10:00:53 +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: <20170919020053.GA10893@tardis> References: <20170917230509.GA21394@linux.vnet.ibm.com> <20170918015353.GA15440@tardis> <20170918142548.GI3521@linux.vnet.ibm.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="G4iJoqBmSsgzjUCe" Content-Disposition: inline In-Reply-To: <20170918142548.GI3521@linux.vnet.ibm.com> User-Agent: Mutt/1.9.0 (2017-09-02) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --G4iJoqBmSsgzjUCe Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Sep 18, 2017 at 07:25:48AM -0700, Paul E. McKenney wrote: > On Mon, Sep 18, 2017 at 03:52:42PM +0800, Boqun Feng wrote: > > On Sun, Sep 17, 2017 at 04:05:09PM -0700, Paul E. McKenney wrote: > > > Hello! > > >=20 > >=20 > > Hi Paul, > >=20 > > > The topic of memory-ordering recipes came up at the Linux Plumbers > > > Conference microconference on Friday, so I thought that I should summ= arize > > > 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/= Examples.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/= Examples.html > >=20 > > Duplicate links ;-) This should a link to some slides? >=20 > Indeed! How about this one? >=20 > http://www.linuxplumbersconf.org/2017/ocw//system/presentations/4708/orig= inal/LKMM-overview.2017.09.15b.pdf >=20 Got it. Thanks for the link ;-) Regards, Boqun > > > 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. > >=20 > > b. replace smp_mb() with smp_mb__before_atomic() followed > > by a _relaxed cmpchg? As in pv_kick_node(): > >=20 > > https://marc.info/?l=3Dlinux-kernel&m=3D150274124711012 > >=20 > > 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? >=20 > Indeed, it would be good to have some single-variable-SC recipes. >=20 > And single-variable-SC holds only if you use READ_ONCE(). ;-) >=20 > Thanx, Paul >=20 --G4iJoqBmSsgzjUCe Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAABCAAdFiEEj5IosQTPz8XU1wRHSXnow7UH+rgFAlnAelIACgkQSXnow7UH +rhqzwf8DLUn95xsZ7bG7/J/LVVNO2DF0SfmCazuTYmsIYSMLGnpREj9TiLOIazL tbDUnsAzVBBGYo76fdMoRxzqq+55zs6Ut8B5ts+oyCAKhpu2S2PSmceVt2ksX3/+ d0P9SjYjIWAz4jsUt4hv4BMIxDMHF3B/1chHp0gNMo1uRHlC99aYX+1eJU8VmyPx /TAXdw3WoWunslPwOsQglgBrt5tLg345UiBW5s9uaczf0ywwj15/+y/5XmZ7JY27 7DofaE0IkKNJhMj31tWMXmTZIVvtQKbF3dFLZrpHak5XLlP/d5aFWu47WswnsPir oUhG+rYCHBANw+tMofM7PfkY9Q2VBQ== =sBhs -----END PGP SIGNATURE----- --G4iJoqBmSsgzjUCe--