Received: by 2002:a89:d88:0:b0:1fa:5c73:8e2d with SMTP id eb8csp602137lqb; Fri, 24 May 2024 07:53:28 -0700 (PDT) X-Forwarded-Encrypted: i=2; AJvYcCX4F/Zd20WA0b1SMEfLhchrOCJoDXtMzpOVAZPERFLGAjSCq56MRh/DJ4IUBHApGLUufsy1K+ITQvlWG9KH4NTgI7YVtzgPRKel+J8Y8g== X-Google-Smtp-Source: AGHT+IFb0sofGbjM53K1eOFCshMDwn6PvUdlzqp+z609ywLK2cNjDWWvsnyv/+HqSedrIq6dGK6i X-Received: by 2002:a05:622a:347:b0:43d:dd37:d067 with SMTP id d75a77b69052e-43fb0e747e8mr26288461cf.16.1716562408407; Fri, 24 May 2024 07:53:28 -0700 (PDT) Return-Path: Received: from ny.mirrors.kernel.org (ny.mirrors.kernel.org. [147.75.199.223]) by mx.google.com with ESMTPS id d75a77b69052e-43fb18b3d74si22406901cf.440.2024.05.24.07.53.28 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 24 May 2024 07:53:28 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel+bounces-188816-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) client-ip=147.75.199.223; Authentication-Results: mx.google.com; arc=fail (body hash mismatch); spf=pass (google.com: domain of linux-kernel+bounces-188816-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) smtp.mailfrom="linux-kernel+bounces-188816-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 ny.mirrors.kernel.org (Postfix) with ESMTPS id 08F2B1C20B52 for ; Fri, 24 May 2024 14:53:28 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 653D512C7FF; Fri, 24 May 2024 14:53:22 +0000 (UTC) Received: from netrider.rowland.org (netrider.rowland.org [192.131.102.5]) by smtp.subspace.kernel.org (Postfix) with SMTP id 0AA1E2BAF3 for ; Fri, 24 May 2024 14:53:19 +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=1716562401; cv=none; b=O4yrZOUxNz29tauxIN7C7HyBO7n5d6nFXrSSIH2+DZWyPxd1hlYwIJrG+63hosMq2wdv6L6Mxf/PKGO60Q/F+nUGFPImjeW/wTULH9U/eIJHoM0ar0Ek25HLzZJrjpyWP7W9jcIRPZ6/5esNtouqpFAYluMbI1hPJdh+SopJ3W4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1716562401; c=relaxed/simple; bh=MU/9caFcN9+jAACsPQtrpOTtABdSUNmXeksHz2iZDGo=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=gogWSBF8aJv4mEow6XQs1j93Pq7WivN5xxasXBiEHDwB+ig0DIoD9p/DkHeTjYrHZYy96AUOIzy2pgL0op1DkddthVo0D7Fqo8XuxQHA0QOWwgOGlVV3ePYnAAA8HYKjiHmjlt0Gs3NEQhuUDfIV3OsKaqI4QnEXF2PF9+q7TDM= 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 576302 invoked by uid 1000); 24 May 2024 10:53:19 -0400 Date: Fri, 24 May 2024 10:53:19 -0400 From: Alan Stern To: Boqun Feng Cc: Hernan Ponce de Leon , Jonas Oberhauser , "Paul E. McKenney" , linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org, kernel-team@meta.com, parri.andrea@gmail.com, j.alglave@ucl.ac.uk, luc.maranget@inria.fr, Joel Fernandes Subject: Re: LKMM: Making RMW barriers explicit Message-ID: References: <58042cf3-e515-4e5f-ab48-1d0d6123c9e9@huaweicloud.com> <6174fd09-b287-49ae-b117-c3a36ef3800a@rowland.harvard.edu> <7bd31eca-3cf3-4377-a747-ec224262bd2e@huaweicloud.com> <35b3fd07-fa85-4244-b9cb-50ea54d9de6a@rowland.harvard.edu> <9256f95a-858b-435f-b40a-a4508a1096c9@rowland.harvard.edu> 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 Fri, May 24, 2024 at 07:34:06AM -0700, Boqun Feng wrote: > On Fri, May 24, 2024 at 10:14:25AM -0400, Alan Stern wrote: > [...] > > > Not really, RMW events contains all events generated from > > > read-modify-write primitives, if there is an R event without a rmw > > > relation (i.e there is no corresponding write event), it's a failed RWM > > > by definition: it cannot be anything else. > > > > Not true. An R event without an rmw relation could be a READ_ONCE(). > > No, the R event is already in the RWM events, it has come from a rwm > atomic. Oh, right. For some reason I was thinking that an instruction could belong to only one set, R or RMW. But that doesn't make sense. > > Or a plain read. The memory model uses the tag to distinguish these > > cases. > > > > > > that it would work is merely an artifact of herd7's internal actions. I > > > > think it would be much cleaner if herd7 represented these events in some > > > > other way, particularly if we can tell it how. > > > > > > > > After all, herd7 already does generate different sets of events for > > > > successful (both R and W) and failed (only R) RMWs. It's not such a big > > > > stretch to make the R events it generates different in the two cases. > > > > > > > > > > I thought we want to simplify the herd internal processing by avoid > > > adding mb events in cmpxchg() cases, in the same spirit, if syntactic > > > tagging is already good enough, why do we want to make herd complicate? > > > > Herd7 already is complicated by the fact that it needs to handle > > cmpxchg() instructions in two ways: success and failure. This > > complication is unavoidable. Adding one extra layer (different tags for > > the different ways) is an insignificant increase in the complication, > > IMO. And it's a net reduction when you compare it to the amount of > > complication currently in the herd7 code. > > > > Also what about cmpxchg_acquire()? If it fails, it will generate an R > > event with an acquire tag not in the rmw relation. There is no way to > > tell such events apart from a normal smp_load_acquire(), and so the .cat > > file would have no way to know that the event should not have acquire > > semantics. I guess we would have to rename this tag, as well. > > No, > > let read_of_rmw = (RMW & R) > let fail_read_of_rmw = read_of_rmw / dom(rmw) > let fail_cmpxchg_acquire = fail_read_of_rmw & [Acquire] > > gives you all the failed cmpxchg_acquire() apart from a normal > smp_load_acquire(). Yes, I see. Using this approach, no further changes to herd7 or the def file would be needed. We would just have to add 'mb to the Accesses enumeration and to the list of tags allowed for an RMW instruction. Question: Since R and RMW have different lists of allowable tags, how does herd7 decide which tags are allowed for an event that is in both the R and RMW sets? Alan