Received: by 2002:ab2:3319:0:b0:1ef:7a0f:c32d with SMTP id i25csp36234lqc; Thu, 7 Mar 2024 09:33:43 -0800 (PST) X-Forwarded-Encrypted: i=3; AJvYcCUROPsvDK9JcXylIVl+ZBIEPJATXUh1APDYm5ilKAHWx0aXNWwDBrQfhPPUP2nprzIqGTAG7uRqMn/XMWB6UbL9EsBkWmmdOpd+7/EPOg== X-Google-Smtp-Source: AGHT+IEHrT+eDlzn3odVF8Lv4VQV0GVbh50GzrmSsrQ69w/S+t4u3CgwJ8OFRYlcIgc9Frr9jiu8 X-Received: by 2002:a17:90a:3d83:b0:29b:3973:ed63 with SMTP id i3-20020a17090a3d8300b0029b3973ed63mr12144995pjc.15.1709832823503; Thu, 07 Mar 2024 09:33:43 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1709832823; cv=pass; d=google.com; s=arc-20160816; b=pbVUxcywiIjWJnwwqvF9DqGE7l6/c9XQEPTBv2sS6S25hvrZHfUaDD7H3l3jeBokt9 3/hp4GINL+faoz12fVpX8gaGRfIqlHteyPJ8l/L3yPD0v5MaatnvlrXkSfHIjJu+vLxL Rzcg63Vrth1KrtqEUO3JGhmveqsfCZwJQPSQDdReDr8MqD2VGAC9G5UoKRQ0oIn9EpS1 TI0HgcE2j064NVZIihp0f9cpge5wPqtW4dEfKsP5CDdcWKrl9qHd7HNciZm/rV1fwPof hg68HnOhRStm19NKE9bWzyB/CTuEBeXHWVO50axnO3dRlUKnCWSvIWVx6U6zezclvOPa 9jNA== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=in-reply-to:content-disposition:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:references:message-id:subject:cc :to:from:date; bh=5RqbwPWRnaxg49eJyoRcIl6Clc3DUEkEwqMZGlwEgpA=; fh=vclOy54vrc4go6iMECrcor6hAewGQ03f2X+1SnH2p10=; b=U0SeLtxlBnr7ORIHoL+qGOy0uYI+p10UbE68T8bTH/VyeU1Jw0An/mZ0UKLbzY5A61 8ePG0obhovc8Q2Y9rsIcJXraI2myxeht9S2h7kTpsdTnXw3YW9CEdpHMassJRahnJZTm 454oRtZwr6u/b/hUUNHG18NX1pAeg6ZEd1F6qCWyWT9jiO981bgiGU7KLYXVsEa2OKJf NZh1YbVxSVRaJ0L8zR32AylQ+LmWewYtnAHaxUDpfEa9LumpoJ33QDVK0w+gr8rS9dkH X9odDckFSNQfNI2Yc+Hh8PEfBqtY2WFTGzkY9rqPVNBZDeAGMNnEqGN+QP1K/Jzr7kcy mVxw==; dara=google.com ARC-Authentication-Results: i=2; mx.google.com; arc=pass (i=1 spf=pass spfdomain=netrider.rowland.org); spf=pass (google.com: domain of linux-kernel+bounces-95935-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.48.161 as permitted sender) smtp.mailfrom="linux-kernel+bounces-95935-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=harvard.edu Return-Path: Received: from sy.mirrors.kernel.org (sy.mirrors.kernel.org. [147.75.48.161]) by mx.google.com with ESMTPS id dr3-20020a056a020fc300b005c5e2c15169si14299722pgb.737.2024.03.07.09.33.42 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 07 Mar 2024 09:33:43 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-95935-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.48.161 as permitted sender) client-ip=147.75.48.161; Authentication-Results: mx.google.com; arc=pass (i=1 spf=pass spfdomain=netrider.rowland.org); spf=pass (google.com: domain of linux-kernel+bounces-95935-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.48.161 as permitted sender) smtp.mailfrom="linux-kernel+bounces-95935-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=harvard.edu Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by sy.mirrors.kernel.org (Postfix) with ESMTPS id C9738B24B53 for ; Thu, 7 Mar 2024 17:26:10 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 6922A130AF1; Thu, 7 Mar 2024 17:26:03 +0000 (UTC) Received: from netrider.rowland.org (netrider.rowland.org [192.131.102.5]) by smtp.subspace.kernel.org (Postfix) with SMTP id 5D22C12D754 for ; Thu, 7 Mar 2024 17:26:00 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.131.102.5 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1709832362; cv=none; b=VtxGwBFD+gwGryEPRVX8o37AG97l+upmCPYCzVzGFLlvUTR8X9pqMkwQfEVQKNq9cpWfjVNHdLAq6P+Lrq6NIPzibxVylKwBjkh4/VPunF2yc+DvLeuqdZJw0OX6pbroH7Txq3j2vRbY/iLuczUYEPDWz90BLnole6HzpvvLph0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1709832362; c=relaxed/simple; bh=SX1AtC2u+6Iy/vuRfN8U8yNJ+dFFIfCxN9dJq7EtE78=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=SuGYB6OYDUE1v+N1QMebitn6IODVfKBLBKgNoIz7wqStEqbmHfhe+gfFvBtM82m2GTl81SUOIfdYiX+crG6tFtCZ0dxP/FezDSjugUQ/Qk8/hgtjwCgKyPFjYc025RIFKEqNjLsdchE0nYfiMTRXdkrvxsDPUvUldo7SxNJL9qU= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=fail (p=none dis=none) header.from=rowland.harvard.edu; spf=pass smtp.mailfrom=netrider.rowland.org; arc=none smtp.client-ip=192.131.102.5 Authentication-Results: smtp.subspace.kernel.org; dmarc=fail (p=none dis=none) header.from=rowland.harvard.edu Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=netrider.rowland.org Received: (qmail 226039 invoked by uid 1000); 7 Mar 2024 12:25:58 -0500 Date: Thu, 7 Mar 2024 12:25:58 -0500 From: Alan Stern To: Andrea Parri Cc: Kenneth-Lee-2012@foxmail.com, linux-kernel@vger.kernel.org, paulmck@kernel.org Subject: Re: Question about PB rule of LKMM Message-ID: References: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: On Thu, Mar 07, 2024 at 04:52:07PM +0100, Andrea Parri wrote: > On Wed, Mar 06, 2024 at 08:24:42PM +0100, Andrea Parri wrote: > > > Later on, the file includes this paragraph, which answers the question > > > you were asking: > > > > > > --------------------------------------------------------------------- > > > The existence of a pb link from E to F implies that E must execute > > > before F. To see why, suppose that F executed first. Then W would > > > have propagated to E's CPU before E executed. If E was a store, the > > > memory subsystem would then be forced to make E come after W in the > > > coherence order, contradicting the fact that E ->coe W. If E was a > > > load, the memory subsystem would then be forced to satisfy E's read > > > request with the value stored by W or an even later store, > > > contradicting the fact that E ->fre W. > > > --------------------------------------------------------------------- > > > > TBF, that just explains (not F ->xb E), or I guess that was the origin > > of the question. Are we talking about the formal xb relation (as mentioned in a comment in linux-kernel.cat), or the informal notion of "executing before" as used in the operational model? In the first case, it's true by definition that pb implies xb, since xb would be defined by: let xb = hb | pb | rb if it were in the memory model. So I guess you're talking about the second, intuitive meaning. That's very simple to explain. Since every instruction executes at _some_ time, and since we can safely assume that no two instructions execute at exactly the _same_ time, if F doesn't execute before E then E must execute before F. Or using your terms, (not F ->xb E) implies (E ->xb F). Would that answer the original question satisfactorily? > So perhaps as in the diff below. (Alan, feel free to manipulate to better > align with the current contents and style of explanation.txt.) > > Andrea > > From c13fd76cd62638cbe197431a16aeea001f80f6ec Mon Sep 17 00:00:00 2001 > From: Andrea Parri > Date: Thu, 7 Mar 2024 16:31:57 +0100 > Subject: [PATCH] tools/memory-model: Amend the description of the pb relation > > To convey why E ->pb F implies E ->xb F in the operational model of > explanation.txt. > > Reported-by: Kenneth Lee > Signed-off-by: Andrea Parri > --- > tools/memory-model/Documentation/explanation.txt | 12 +++++------- > 1 file changed, 5 insertions(+), 7 deletions(-) > > diff --git a/tools/memory-model/Documentation/explanation.txt b/tools/memory-model/Documentation/explanation.txt > index 6dc8b3642458e..68af5effadbbb 100644 > --- a/tools/memory-model/Documentation/explanation.txt > +++ b/tools/memory-model/Documentation/explanation.txt > @@ -1461,13 +1461,11 @@ The case where E is a load is exactly the same, except that the first > link in the sequence is fre instead of coe. > > The existence of a pb link from E to F implies that E must execute > -before F. To see why, suppose that F executed first. Then W would > -have propagated to E's CPU before E executed. If E was a store, the > -memory subsystem would then be forced to make E come after W in the > -coherence order, contradicting the fact that E ->coe W. If E was a > -load, the memory subsystem would then be forced to satisfy E's read > -request with the value stored by W or an even later store, > -contradicting the fact that E ->fre W. > +before F. To see why, let W be a store coherence-later than E and > +propagating to every CPU and to RAM before F executes. Then E must > +execute before W propagates to E's CPU (since W is coherence-later > +than E). In turn, W propagates to E's CPU (and every CPU) before F > +executes. The new text says the same thing as the original, just in a more condensed way. It skips the detailed explanation of why E must execute before W propagates to E's CPU, merely saying that it is because "W is coherence-later than E". I'm not sure this is an improvement; the reader might want to know exactly how this reasoning goes. Would it suit you to instead add an extra sentence to the end of the paragraph, something like this? These contradictions show that E must execute before W propagates to E's CPU, hence before W propagates to every CPU, and hence before F executes. Alan Stern