Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp573794imm; Fri, 13 Jul 2018 02:36:11 -0700 (PDT) X-Google-Smtp-Source: AAOMgpc11NlakyH48FZI2f+X7aFX8ldzCKaKAmbB0k+U+NMYru/8d5MwL5bedaWvV1opEdWXRIJQ X-Received: by 2002:a63:7007:: with SMTP id l7-v6mr5425988pgc.206.1531474570962; Fri, 13 Jul 2018 02:36:10 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1531474570; cv=none; d=google.com; s=arc-20160816; b=qfjaMSyXr+USRZ3/EUDTaigGiy3JqJcqJf462lFCXU7ofY0bXtkCYS9C/5J7VKrLBO 7Joe826E3xUwSDKPAdqHjtD5SnQ9Abb0Q8lrlABbJipVJ+Epv3pa2opcE/7xB7LuINW0 yaYdZkx6fXpoaBdfbbxVsPhmwQObzckRprAKqZTmf8Ru3KcgEkvJkAUKeSu8aQDk3Qjr s6hFfKqg2FovmmKoLcyZ2SuQeUUBZDD9bJFLuTnc2NaycaTSEc743v/ePGsV3S/ubBsn hc2Zc6Xyw8QL2x8ZQp6W8WfaftQJ3EeA8y9BBATUZKdLnJQstDyETENOfcxtMq1XYlCJ Rd6g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:arc-authentication-results; bh=GuKDyDpCZv0rrVa7JR6HOWx1Dnptm8c8GILyG/J3mFM=; b=gszQ6iFDHX3i59cXGrJ7wr1tax1OEgFnxINcofgvBu1q8ITcmyIvraOqsJ66ba2fZv kPinWqz2X8is2Gc/xoYvV/XMz018mBPFqUQUaxvK813dH/YZhPSS7GX6NDUdm/Tw64Ac jUfcS2YcVt68ksfzjW/4vyS5yrO0QtNx0WCLz+1AN3+97wD4vEpu6sHbUTU+lOlyI5Cx a/v2nleaUJF1vHA0j9HAEsoYbmBgKkoyoGmgeUmLZEy/8zLg/+1/X2eMEiJ/MYe2n51X gveJ8G4k96M2hblMdvYREktmeHsTCvH9+SumY1JBkfboTtCkMDrHf8OxH7w15qNf+q+2 R7jw== 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 c16-v6si22288122pgw.460.2018.07.13.02.35.56; Fri, 13 Jul 2018 02:36:10 -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 S1728289AbeGMJse (ORCPT + 99 others); Fri, 13 Jul 2018 05:48:34 -0400 Received: from usa-sjc-mx-foss1.foss.arm.com ([217.140.101.70]:60506 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726824AbeGMJsd (ORCPT ); Fri, 13 Jul 2018 05:48:33 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id E8B77ED1; Fri, 13 Jul 2018 02:34:42 -0700 (PDT) Received: from edgewater-inn.cambridge.arm.com (usa-sjc-imap-foss1.foss.arm.com [10.72.51.249]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPA id B95823F5AD; Fri, 13 Jul 2018 02:34:42 -0700 (PDT) Received: by edgewater-inn.cambridge.arm.com (Postfix, from userid 1000) id 5A5371AE35DD; Fri, 13 Jul 2018 10:35:25 +0100 (BST) Date: Fri, 13 Jul 2018 10:35:25 +0100 From: Will Deacon To: Andrea Parri Cc: Daniel Lustig , Linus Torvalds , Peter Zijlstra , Paul McKenney , Alan Stern , Akira Yokosawa , Boqun Feng , David Howells , Jade Alglave , Luc Maranget , Nick Piggin , Linux Kernel Mailing List Subject: Re: [PATCH v2] tools/memory-model: Add extra ordering for locks and remove it for ordinary release/acquire Message-ID: <20180713093524.GC32020@arm.com> References: <20180712134821.GT2494@hirez.programming.kicks-ass.net> <20180712172838.GU3593@linux.vnet.ibm.com> <20180712180511.GP2476@hirez.programming.kicks-ass.net> <11b27d32-4a8a-3f84-0f25-723095ef1076@nvidia.com> <20180713090637.GA10601@andrea> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180713090637.GA10601@andrea> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Jul 13, 2018 at 11:07:11AM +0200, Andrea Parri wrote: > On Thu, Jul 12, 2018 at 07:05:39PM -0700, Daniel Lustig wrote: > > On 7/12/2018 11:10 AM, Linus Torvalds wrote: > > > On Thu, Jul 12, 2018 at 11:05 AM Peter Zijlstra wrote: > > >> > > >> The locking pattern is fairly simple and shows where RCpc comes apart > > >> from expectation real nice. > > > > > > So who does RCpc right now for the unlock-lock sequence? Somebody > > > mentioned powerpc. Anybody else? > > > > > > How nasty would be be to make powerpc conform? I will always advocate > > > tighter locking and ordering rules over looser ones.. > > > > > > Linus > > > > RISC-V probably would have been RCpc if we weren't having this discussion. > > Depending on how we map atomics/acquire/release/unlock/lock, we can end up > > producing RCpc, "RCtso" (feel free to find a better name here...), or RCsc > > behaviors, and we're trying to figure out which we actually need. > > > > I think the debate is this: > > > > Obviously programmers would prefer just to have RCsc and not have to figure out > > all the complexity of the other options. On x86 or architectures with native > > RCsc operations (like ARMv8), that's generally easy enough to get. > > > > For weakly-ordered architectures that use fences for ordering (including > > PowerPC and sometimes RISC-V, see below), though, it takes extra fences to go > > from RCpc to either "RCtso" or RCsc. People using these architectures are > > concerned about whether there's a negative performance impact from those extra > > fences. > > > > However, some scheduler code, some RCU code, and probably some other examples > > already implicitly or explicitly assume unlock()/lock() provides stronger > > ordering than RCpc. So, we have to decide whether to: > > 1) define unlock()/lock() to enforce "RCtso" or RCsc, insert more fences on > > PowerPC and RISC-V accordingly, and probably negatively regress PowerPC > > 2) leave unlock()/lock() as enforcing only RCpc, fix any code that currently > > assumes something stronger than RCpc is being provided, and hope people don't > > get it wrong in the future > > 3) some mixture like having unlock()/lock() be "RCtso" but smp_store_release()/ > > smp_cond_load_acquire() be only RCpc > > > > Also, FWIW, if other weakly-ordered architectures come along in the future and > > also use any kind of lightweight fence rather than native RCsc operations, > > they'll likely be in the same boat as RISC-V and Power here, in the sense of > > not providing RCsc by default either. > > > > Is that a fair assessment everyone? > > It's for me, thank you! And as we've seen, there are arguments for each of > the above three choices. I'm afraid that (despite Linus's statement ;-)), > my preference would currently go to (2). And, since we're stating preferences, I'll reiterate my preference towards: * RCsc unlock/lock * RCpc release/acquire * Not fussed about atomic rmws, but having them closer to RCsc 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) Will