Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp1090380imm; Wed, 11 Jul 2018 17:08:14 -0700 (PDT) X-Google-Smtp-Source: AAOMgpd/2oaxPCS091gukk0NbvwgoSB8by0p5xg0tGxOhGu6Oqasdyj+BVLMdb993m3vMCmOtRW1 X-Received: by 2002:a17:902:599b:: with SMTP id p27-v6mr633612pli.191.1531354094367; Wed, 11 Jul 2018 17:08:14 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1531354094; cv=none; d=google.com; s=arc-20160816; b=fB29xMxt9CQipGwB11RlTKWXhQTOGGw2u0a8D9eGgJ843+lPQY9omaMdH2TCUWc6IY /Z2QUJToK8cLSm2WcJX40lRjGoDzlupZ+ZxDUlor/ZZ01VSalqJiN0ROUOBTqV04yfP3 b1Jro/AkHSYoVxivji7DkJEIBzUnGgbsorjkW4dSZLwKNfWV18/9M+QyFvT+YNTTmmOI 9hhMTroq7yZVFWuU/3MT4lPWejymOAVa8Y+HVKXHRreZt5UiD0GjQ4vQOA+boXZbgo3P il9hoswgo9zrzVoli9b3UIl0yG8nTR1dq56UajSamiPW4mtca+K4/cYQMtTCV8f0b1ki w5JA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:arc-authentication-results; bh=GLuPrEKVet6Y+fHnc8UquQrhCLsPCHPVbmF8gw+noNo=; b=QWssioz0aAfe0RZLn6GMZIwyi4OHx4IhaDzz+Pk0bnJBpkdzPUHZWpXt8NXeef4lNK GfcVRP9zUEVTlOsAVU4Zg02hjRGKDiM2UQJoIg6TZx1Rw3F/dxw9K5j45R4LoO/iyLOU EXTeJl7cD7UrnWXOan8/EVSQNGGgdmfKpJLS7DlkOrT3TTpq9y5Qv26Cyto97NUwWDdg 4cDW8LVA7+ym9iqT9V2HeK2McchrJhVdRq1BOgIlnwXL7bUH16lu0qPz/WpFACHc3QtJ KMFXTCVTMtd2DepWHvl6dwNMrwfAGC6krYe3Wb/YQhvd0n+5gWG6gqwx4xfYc/4tZJLN 9H9A== 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=nvidia.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id g1-v6si20556023pld.11.2018.07.11.17.07.59; Wed, 11 Jul 2018 17:08:14 -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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=nvidia.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2389116AbeGKR4X (ORCPT + 99 others); Wed, 11 Jul 2018 13:56:23 -0400 Received: from hqemgate14.nvidia.com ([216.228.121.143]:19296 "EHLO hqemgate14.nvidia.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1732456AbeGKR4X (ORCPT ); Wed, 11 Jul 2018 13:56:23 -0400 Received: from hqpgpgate101.nvidia.com (Not Verified[216.228.121.13]) by hqemgate14.nvidia.com (using TLS: TLSv1, AES128-SHA) id ; Wed, 11 Jul 2018 10:50:55 -0700 Received: from HQMAIL105.nvidia.com ([172.20.161.6]) by hqpgpgate101.nvidia.com (PGP Universal service); Wed, 11 Jul 2018 10:50:57 -0700 X-PGP-Universal: processed; by hqpgpgate101.nvidia.com on Wed, 11 Jul 2018 10:50:57 -0700 Received: from [10.110.39.62] (10.110.39.62) by HQMAIL105.nvidia.com (172.20.187.12) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Wed, 11 Jul 2018 17:50:57 +0000 Subject: Re: [PATCH v2] tools/memory-model: Add extra ordering for locks and remove it for ordinary release/acquire To: Peter Zijlstra , Will Deacon CC: Andrea Parri , Alan Stern , "Paul E. McKenney" , LKMM Maintainers -- Akira Yokosawa , Boqun Feng , David Howells , Jade Alglave , Luc Maranget , Nicholas Piggin , Kernel development list References: <20180710093821.GA5414@andrea> <20180711094310.GA13963@arm.com> <20180711123421.GA9673@andrea> <20180711155751.GC18477@arm.com> <20180711170053.GM2476@hirez.programming.kicks-ass.net> From: Daniel Lustig Message-ID: Date: Wed, 11 Jul 2018 10:50:56 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.0 MIME-Version: 1.0 In-Reply-To: <20180711170053.GM2476@hirez.programming.kicks-ass.net> X-Originating-IP: [10.110.39.62] X-ClientProxiedBy: HQMAIL105.nvidia.com (172.20.187.12) To HQMAIL105.nvidia.com (172.20.187.12) Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 7/11/2018 10:00 AM, Peter Zijlstra wrote: > On Wed, Jul 11, 2018 at 04:57:51PM +0100, Will Deacon wrote: > >> It might be simple to model, but I worry this weakens our locking >> implementations to a point where they will not be understood by the average >> kernel developer. As I've said before, I would prefer "full" RCsc locking, > > Another vote for RCsc locks. The (in)famous hold-out is of course > PowerPC, but it now looks like RISC-V is following where they I really > rather wish they didn't. That's not entirely fair. We came in wanting to do the "natural" or "expected" thing: use RCsc atomics where we have them available in the ISA, and use "fence r,rw" and "fence rw,w" where we don't. I would argue that the idea of having data races on variables that are also protected by locks is equally if not more counterintuitive and unexpected than the "natural" mapping we had originally proposed to use. All the discussion here[1] for example is about having ordering and doing an smp_cond_load_acquire() on a variable which is sometimes protected by a CPU's rq->lock and sometimes not? Isn't that one of the key use cases for this whole discussion? FWIW, this code also mixes locking, smp_rmb(), and smp_cond_load_acquire() all in very close proximity with each other... I suppose there's no mixing and matching on the same variable, but we are here trying to reason about how all those pieces interact, no? [1] https://lkml.org/lkml/2015/10/6/805 Dan