From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id F2642C05027 for ; Mon, 23 Jan 2023 20:42:18 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232203AbjAWUlw (ORCPT ); Mon, 23 Jan 2023 15:41:52 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42934 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232711AbjAWUlf (ORCPT ); Mon, 23 Jan 2023 15:41:35 -0500 Received: from netrider.rowland.org (netrider.rowland.org [192.131.102.5]) by lindbergh.monkeyblade.net (Postfix) with SMTP id AB5548A5B for ; Mon, 23 Jan 2023 12:41:08 -0800 (PST) Received: (qmail 140283 invoked by uid 1000); 23 Jan 2023 15:41:08 -0500 Date: Mon, 23 Jan 2023 15:41:08 -0500 From: Alan Stern To: Jonas Oberhauser Cc: Jonas Oberhauser , "paulmck@kernel.org" , Peter Zijlstra , "parri.andrea" , will , "boqun.feng" , npiggin , dhowells , "j.alglave" , "luc.maranget" , akiyks , dlustig , joel , urezki , quic_neeraju , frederic , Kernel development list Subject: Re: Internal vs. external barriers (was: Re: Interesting LKMM litmus test) Message-ID: References: <20220921173109.GA1214281@paulmck-ThinkPad-P17-Gen-1> <114ECED5-FED1-4361-94F7-8D9BC02449B7> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Jan 23, 2023 at 09:06:54PM +0100, Jonas Oberhauser wrote: > > > On 1/23/2023 8:58 PM, Alan Stern wrote: > > On Mon, Jan 23, 2023 at 05:16:27PM +0100, Jonas Oberhauser wrote: > > > On 1/19/2023 5:41 PM, Alan Stern wrote: > > > > > > > But when you're comparing grace periods or critical sections to each other, > > > > things get a little ambiguous. Should G1 be considered to come before > > > > G2 when t1(G1) < t1(G2), when t2(G1) < t2(G2), or when t2(G1) < t1(G2)? > > > > Springing for (po ; rcu-order ; po?) amounts to choosing the second > > > > alternative. > > > Aha, I see! Powerful notation indeed. > > > Keeping that in mind, wouldn't it make sense for pb also be changed to > > > `...;po?` ? > > You mean changing the definition of pb to either: > > > > prop ; strong-fence ; hb* ; po? ; [Marked] > > > > or > > > > prop ; strong-fence ; hb* ; [Marked] ; po? ; [Marked] > > Oh no, not at all! > > I mean that >     pb = prop ; po ; {strong ordering-operation} ; po ; hb* ; [Marked] > could instead be >     pb = prop ; po ; {strong ordering-operation} ; po? ; hb* ; [Marked] > > (note that the po ; ... ; po part is actually folded inside the actual > definition of strong fence). This goes back to the original herd models, before the LKMM came about: The fencerel() macro uses po on both sides. I believe the motivating idea back then was that ordering should apply only to memory accesses (which can in practice be observed), not to other types of events such as memory barriers. > > rcu-fence is different because rcu-order has to begin and end with > > either a grace period or a critical section, and both of these restrict > > the execution order of surrounding events: > > > > If X is a synchronize_rcu() or rcu_read_unlock() then events > > po-before X must execute before X; > > > > If X is a synchronize_rcu() or rcu_read_lock() then events > > po-after X must execute after X. > > > I believe so do the strong ordering-operations in pb. But the beginning and end of a pb link (for example, overwrite and hb) don't need to be strong-ordering operations. Alan