Received: by 2002:ac0:a5a6:0:0:0:0:0 with SMTP id m35-v6csp21828imm; Thu, 30 Aug 2018 14:33:17 -0700 (PDT) X-Google-Smtp-Source: ANB0VdafLqgpHL0NyvP5h2Fs8kPJYLRHWL9JETt7lXlyIkU92g4pgOpKMfik+ki4KH9SpJRst8ux X-Received: by 2002:a63:de10:: with SMTP id f16-v6mr11394421pgg.97.1535664797443; Thu, 30 Aug 2018 14:33:17 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1535664797; cv=none; d=google.com; s=arc-20160816; b=KVJbdNNNscCarPlPJEhhW3LSDWn/TLVEEXzp+TG96j+qvVOfI7eEVheGkElDGnqlTx 67IC6K0/iw/f6OL1vnKoCweqceLnUUj8KAiJ1E7Ad6BqxRDlkqdrPk6vT+t/gLNgvZOT SoPVxUiFRqORreuZ/A3pWXOng08YdtmSPX+wopkXcnL0U6sjNHXx2AqSdFPu5T2PrDPh qJ+bt5TSwR4WvQLCPR7srGP2V8kdalx3O7Bq+GcHgojm84NF6dPlc5E6jQAG6gptEjkS 4YDTC2UbCRHW8eMDaTy6W6AIGkPXnzdPLahacd6ioRNrW/EnwnKN5D9if8sRzCX3x0Hz eiPg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:message-id:in-reply-to :subject:cc:to:from:date:arc-authentication-results; bh=lSNOGQ6Qn9K80BAKe8uOb/9fygDbKgqX12ZMmvk30S8=; b=P5OOCP2SgT4pHdKDzaFZZAwU3BfMEYnq9eCsQtKvAQnGjjPbQrFgayokVWfdOwA8SI KCmvdzoxSg5YIFU+v05phPbO2FoEaS1/QoGfQZy1K+1A/5Cy+zi/OMLvpCKNo86RR0I4 MzuLLcO8ERF6FW133Dcnh2JPjt2pItO8gSTJXFqfhzrHSw9vCWh9JfZU8jLdxdvlAhJt MPHAFQY4VroEv//Zf/ge6dPAn5HfKzAJX/S5idN56dfrDX5fkAWKFNlHeJ//qGrIyzTs LaIZKOngYNgu6/G9N116WqIBAm1iohg3T73QmsnNj8UU7VjsTWU7xYl6rCgwGf6ttabF qdgw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 15-v6si7587593pgu.205.2018.08.30.14.33.02; Thu, 30 Aug 2018 14:33:17 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727569AbeHaBfl (ORCPT + 99 others); Thu, 30 Aug 2018 21:35:41 -0400 Received: from netrider.rowland.org ([192.131.102.5]:45925 "HELO netrider.rowland.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP id S1727235AbeHaBfl (ORCPT ); Thu, 30 Aug 2018 21:35:41 -0400 Received: (qmail 2843 invoked by uid 500); 30 Aug 2018 17:31:32 -0400 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 30 Aug 2018 17:31:32 -0400 Date: Thu, 30 Aug 2018 17:31:32 -0400 (EDT) From: Alan Stern X-X-Sender: stern@netrider.rowland.org To: Andrea Parri cc: "Paul E. McKenney" , , , , , , , , , , , Subject: Re: [PATCH RFC LKMM 1/7] tools/memory-model: Add extra ordering for locks and remove it for ordinary release/acquire In-Reply-To: <20180830125045.GA6936@andrea> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 30 Aug 2018, Andrea Parri wrote: > > All the architectures supported by the Linux kernel (including RISC-V) > > do provide this ordering for locks, albeit for varying reasons. > > Therefore this patch changes the model in accordance with the > > developers' wishes. > > > > Signed-off-by: Alan Stern > > Signed-off-by: Paul E. McKenney > > Reviewed-by: Will Deacon > > Acked-by: Peter Zijlstra (Intel) > > Round 2 ;-), I guess... Let me start from the uncontroversial points: > > 1) being able to use the LKMM to reason about generic locking code > is useful and desirable (paraphrasing Peter in [1]); > > 2) strengthening the ordering requirements of such code isn't going > to boost performance (that's "real maths"). > > This patch is taking (1) away from us and it is formalizing (2), with > almost _no_ reason (no reason at all, if we stick to the commit msg.). That's not quite fair. Generic code isn't always universally applicable; some of it is opt-in -- meant only for the architectures that can support it. In general, the LKMM allows us to reason about higher abstractions (such as locking) at a higher level, without necessarily being able to verify the architecture-specific details of the implementations. > In [2], Will wrote: > > "[...] having them [the RMWs] closer to RCsc[/to the semantics of > locks] would make it easier to implement and reason about generic > locking implementations (i.e. reduce the number of special ordering > cases and/or magic barrier macros)" > > "magic barrier macros" as in "mmh, if we accept this patch, we _should_ > be auditing the various implementations/code to decide where to place a > > smp_barrier_promote_ordinary_release_acquire_to_unlock_lock()" ;-) > > or the like, and "special ordering cases" as in "arrgh, (otherwise) we > are forced to reason on a per-arch basis while looking at generic code". Currently the LKMM does not permit architecture-specific reasoning. It would have to be extended (in a different way for each architecture) first. For example, one could use herd's POWER model combined with the POWER compilation scheme and the POWER-specific implementation of spinlocks for such reasoning. The LKMM alone is not sufficient. Sure, programming and reasoning about the kernel would be easier if all architectures were the same. Unfortunately, we (and the kernel) have to live in the real world. > (Remark: ordinary release/acquire are building blocks for code such as > qspinlock, (q)rwlock, mutex, rwsem, ... and what else??). But are these building blocks used the same way for all architectures? > To avoid further repetition, I conclude by confirming all the concerns > and my assessment of this patch as pointed out in [3]; the subsequent > discussion, although not conclusive, presented several suggestions for > improvement (IMO). Alan