From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751867AbdG0OrD (ORCPT ); Thu, 27 Jul 2017 10:47:03 -0400 Received: from mail-pf0-f193.google.com ([209.85.192.193]:35330 "EHLO mail-pf0-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751641AbdG0OrB (ORCPT ); Thu, 27 Jul 2017 10:47:01 -0400 Date: Thu, 27 Jul 2017 22:47:03 +0800 From: Boqun Feng To: "Paul E. McKenney" Cc: Peter Zijlstra , linux-kernel@vger.kernel.org, mingo@kernel.org, jiangshanlai@gmail.com, dipankar@in.ibm.com, akpm@linux-foundation.org, mathieu.desnoyers@efficios.com, josh@joshtriplett.org, tglx@linutronix.de, rostedt@goodmis.org, dhowells@redhat.com, edumazet@google.com, fweisbec@gmail.com, oleg@redhat.com, will.deacon@arm.com Subject: Re: [PATCH tip/core/rcu 4/5] sys_membarrier: Add expedited option Message-ID: <20170727144703.v2gxtrv4plcduj2l@tardis> References: <20170725215510.GD28975@worktop> <20170725235936.GC3730@linux.vnet.ibm.com> <20170726074128.ybb3e4flnjkrpi74@hirez.programming.kicks-ass.net> <20170726154110.GN3730@linux.vnet.ibm.com> <20170727083003.ivb2fr47vepa2g6t@hirez.programming.kicks-ass.net> <20170727130816.GP3730@linux.vnet.ibm.com> <20170727135551.tg7cduw22krjzbvt@tardis> <20170727141633.GT3730@linux.vnet.ibm.com> <20170727142955.bb2bdgbjcm745xwo@tardis> <20170727143658.GW3730@linux.vnet.ibm.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="7hp22yhzomzmsapw" Content-Disposition: inline In-Reply-To: <20170727143658.GW3730@linux.vnet.ibm.com> User-Agent: NeoMutt/20170609 (1.8.3) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --7hp22yhzomzmsapw Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jul 27, 2017 at 07:36:58AM -0700, Paul E. McKenney wrote: > > >=20 > > > The reporting of the quiescent state will acquire the leaf rcu_node > > > structure's lock, with an smp_mb__after_unlock_lock(), which will > > > one way or another be a full memory barrier. So the reorderings > > > cannot happen. > > >=20 > > > Unless I am missing something subtle. ;-) > > >=20 > >=20 > > Well, smp_mb__after_unlock_lock() in ARM64 is a no-op, and ARM64's lock > > doesn't provide a smp_mb(). > >=20 > > So my point is more like: synchronize_sched() happens to be a > > sys_membarrier() because of some implementation detail, and if some day > > we come up with a much cheaper way to implement sched flavor > > RCU(hopefully!), synchronize_sched() may be not good for the job. So at > > least, we'd better document this somewhere? >=20 > Last I heard, ARM's unlock/lock acted as a full barrier. Will? >=20 > Please see the synchronize_sched() comment header for the documentation > you are asking for. And the "Memory-Barrier Guarantees" section of > Documentation/RCU/Design/Requirements/Requirements.html. >=20 All those barrier guarantees are subject to a RCU read-side critical section with a synchonize_*(), IIRC, for example: * On systems with more than one CPU, when synchronize_sched() returns, * each CPU is guaranteed to have executed a full memory barrier since the * end of its last RCU-sched read-side critical section whose beginning * preceded the call to synchronize_sched(). In addition, each CPU having , which is not the case for a quiesent state without a read-side critical section(i.e. non-context-switch quiesent state for sched Flavor) I've read those requirements and could not find one to explain why there will be a full barrier emitted in an interrupted user-space program. Regards, Boqun > Thanx, Paul >=20 > > Regards, > > Boqun > >=20 > > > Thanx, Paul > > >=20 > > > > | | > > > > read Y; --------------------------------------+----+ > > > > store X; | > > > > {read X}(reordered) <-------------------------+ > > > >=20 > > > > I assume the timer interrupt handler, which interrupts a user space= and > > > > reports a quiesent state for sched flavor RCU, may not have a smp_m= b() > > > > in some code path. > > > >=20 > > > > I may miss something subtle, but it just not very obvious how > > > > synchronize_sched() will guarantee a remote CPU running in userspac= e to > > > > do a smp_mb() before it returns, this is at least not in RCU > > > > requirements, right? > > > >=20 > > > > Regards, > > > > Boqun > > >=20 > > >=20 >=20 >=20 --7hp22yhzomzmsapw Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAABCAAdFiEEj5IosQTPz8XU1wRHSXnow7UH+rgFAll5/N4ACgkQSXnow7UH +rgJUwf8C97GFXh7us1OuwRJrBAJCXebICTctVZM7GavoHDOIygjvo/0ETzKSFaB RKrE5tgkiutMQMjYIBi7Lbd6xFtDhQJyxD6iOGrya9FNoy4X2gcDKWIsZFFvu0pJ qroIjK+RnuzdPROUlEXp2I0MdzXp9MPoEqVI5fZLhzdrojRkzayo7rrL+b3rUPK4 /gizrG7/GcqtfJbDh2o9+YynIniD3hVddmUhk37qFXh4C1fABj8ag3Z/VgZ3fdZX k4YLvOA45SDLAEDRNvb22qQIXlNwPZSpx940ZMLxkozgS7Tc8F2AUQwqUdvttpBu Anc2wBdX4KfaDp6o8gm4oqbqosHFyQ== =RWKV -----END PGP SIGNATURE----- --7hp22yhzomzmsapw--