Received: by 2002:a05:6a10:eb17:0:0:0:0 with SMTP id hx23csp789668pxb; Thu, 9 Sep 2021 12:04:43 -0700 (PDT) X-Google-Smtp-Source: ABdhPJw+Gtcrqza6tbK3ws5MaJKiu4o2cNsUR0MMmxitpxm4eQ6w+8sIMf3+vJlR9yU/I5FgjgYM X-Received: by 2002:adf:ec8b:: with SMTP id z11mr5438235wrn.122.1631214282929; Thu, 09 Sep 2021 12:04:42 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1631214282; cv=none; d=google.com; s=arc-20160816; b=0iA8MNwBYSaf81uDnk7B/cHJDSlbSr1EDYPpc3+/NOkvFCPttV5MD3e8nEbwFIiSSw tN6zS63YcNKc2BkNl6cnxBGV6F73McdB2AMZbYRm+jI2Istx1lN3fQvLKUYqYGa2eeaq ibwN6lHY+Yi71GxVv/cRuztzwjp4ZkYfvyZi/B9WQUogtMJo2G2A1gIe4hzDcaH9Mrxn NVHg77xUCriDTxGeunA1++Kl72gdV/8YUmzzsnIVzkv6NVQ2HgxP0MUpkXZDsivg47ZT N+5Y/7CRyzITmzHY+ZCDJvZi+UtgmcXoAHqevxfMm2Af7Kt3gIDyUpFmZv/tVBXgUle8 UpRQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=0h1HJDFoUCIGHC0gpufFGxWrBPqfIgjMTnx6hIxSQ5k=; b=eCcmVSfW6vZhl9U49YRaf9TtPis4TXVpnJZDdu+DY7dwynUWSgzSusOjzLW9mfZ0PV erd8MMkiwRzZ2mm6w0yBFYaoYnFUwxWzoQlpw0GAuLlyKK+HkZlWNpW0uw9q1wXHdarj ow+tZd29faDPdHMcT5hVNcHpJLKx+z2e0qvRRKpaS9lpRN4ChpCCJYJa69vpuAyl/JWd ZmATyIcx/+i7Vqplbx3B9HyipCGzsSK+z59H145TEJ+IXVckYWT+jv4b2CDIuwPtNxnU NizpVrieL7qn5OJe8TBmWAaOJMqGgrNtUn550XMpDL4nOFxDW2NB9738zFFi0Ammka+E l+pw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id y13si34209edm.398.2021.09.09.12.04.08; Thu, 09 Sep 2021 12:04:42 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236112AbhIITAt (ORCPT + 99 others); Thu, 9 Sep 2021 15:00:49 -0400 Received: from netrider.rowland.org ([192.131.102.5]:56163 "HELO netrider.rowland.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP id S231422AbhIITAs (ORCPT ); Thu, 9 Sep 2021 15:00:48 -0400 Received: (qmail 13113 invoked by uid 1000); 9 Sep 2021 14:59:37 -0400 Date: Thu, 9 Sep 2021 14:59:37 -0400 From: Alan Stern To: Linus Torvalds Cc: Will Deacon , Peter Zijlstra , Alexander Shishkin , Peter Anvin , Andrea Parri , Ingo Molnar , "Paul E. McKenney" , Vince Weaver , Thomas Gleixner , Jiri Olsa , Arnaldo Carvalho de Melo , Linux Kernel Mailing List , Stephane Eranian , linux-tip-commits@vger.kernel.org, Palmer Dabbelt , Paul Walmsley , Daniel Lustig , Michael Ellerman Subject: Re: [tip:locking/core] tools/memory-model: Add extra ordering for locks and remove it for ordinary release/acquire Message-ID: <20210909185937.GA12379@rowland.harvard.edu> References: <20180926182920.27644-2-paulmck@linux.ibm.com> <20210908144217.GA603644@rowland.harvard.edu> <20210909133535.GA9722@willie-the-truck> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Sep 09, 2021 at 10:02:13AM -0700, Linus Torvalds wrote: > On Thu, Sep 9, 2021 at 6:35 AM Will Deacon wrote: > > > > I don't think we should require the accesses to the actual lockwords to > > be ordered here, as it becomes pretty onerous for relaxed LL/SC > > architectures where you'd end up with an extra barrier either after the > > unlock() or before the lock() operation. However, I remain absolutely in > > favour of strengthening the ordering of the _critical sections_ guarded by > > the locks to be RCsc. > > Ack. The actual locking operations themselves can obviously overlap, > it's what they protect that should be ordered if at all possible. > > Because anything else will be too confusing for words, and if we have > to add memory barriers *and* locking we're just screwed. > > Because I think it is entirely understandable for people to expect > that sequence of two locked regions to be ordered wrt each other. > > While memory ordering is subtle and confusing, we should strive to > make our "..but I used locks" to be as straightforward and as > understandable to people who really really don't want to even think > about memory order as at all reasonable. > > I think we should have a very strong reason for accepting unordered > locked regions (with "strong reason" being defined as "on this > architecture that is hugely important, anything else would slow down > locks enormously"). > > It sounds like no such architecture exists, much less is important. All right. Currently the memory model has RCtso ordering of accesses in separate critical sections for the same lock, as observed by other CPUs not holding the lock. Peter is proposing (and Linus agrees) to expand this to cover critical sections for different locks, so long as both critical sections are on the same CPU. But he didn't propose strengthening the ordering to RCsc, and I presume we don't want to do this because of the slowdown it would incur on Power. Does everyone agree that this correctly summarizes the change to be made to the memory model? Alan