Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp276864imm;
        Thu, 12 Jul 2018 19:20:13 -0700 (PDT)
X-Google-Smtp-Source: AAOMgpdE7KIa4XF9tsanmrz1R0iUnyxYXwx67+/cD3NcUzWoVN9uzgwGuezBhIDtI5+zTWJ4g26X
X-Received: by 2002:a63:6b86:: with SMTP id g128-v6mr4376724pgc.344.1531448412980;
        Thu, 12 Jul 2018 19:20:12 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; t=1531448412; cv=none;
        d=google.com; s=arc-20160816;
        b=deBejjQoV/PWSrhRvCji4A4sN61/GbnC0ysiesobl8u9jA9iW1JXYBpolnU8fJFDrF
         ZwrXUdh/5Ptw2KzmIeZpZpTw70GC6F3fos6h4XlJP/ecc0wpctg2HqF+kGNoRZPOEkkz
         fIMzS7UFS5ogjGYfp8TihlsXBG6bu69S8ZE2ygrz17mkjXKan2bCKL3ICwkAdDhcWGv4
         3EIoIeDqyQG4wBnSbaIrr7t13AwKuHeZMIssn7mnEeWhsSaeB/pO+5YT0muxDUMcrFS7
         66QLzE/t3yde9Q1/TPnEu+nOmDfTKDlUxOTKO0Ak3WUHYgjkzFi8o8e90gHAqrb1udwA
         g5fQ==
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=U0DPYrbOYkkwN8txmECDr2dW21eq0A+X74vsLdKyPE0=;
        b=J5E2XKyQQfeatNMaTI7FVcWFZWZUR+EpTQaQjphe5vceRm1VSku+UfELCbPBb6tkwK
         Vfj1hIY97o8s1IkaYNwEAViOAdd7BybYydTLq9XeoxZgDgXw3gcUHEMQUs9QIOOAPGUA
         b/rO8NF+y7SYDGfWkgqgZICQdkeWBRjwh/5WbUEAufhTAf8w8MYNdXnJnesXNd5u05t0
         lL3I4FN2sZlYNF2fBJa8DmLHNGz8crs5qeGQAJZPxR180alfEN6FN0mJwY1Eint8rHJm
         WGdmvZkofnuNiOi8K390VpOVCrIfe1PVyFpF+cYYjzLt9pK0tZpZmoC9dZCFJ9htoWgD
         Z3gQ==
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: <linux-kernel-owner@vger.kernel.org>
Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67])
        by mx.google.com with ESMTP id i8-v6si21166471pgs.211.2018.07.12.19.19.57;
        Thu, 12 Jul 2018 19:20:12 -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 S2388076AbeGMCaL (ORCPT <rfc822;speed.demon0047@gmail.com>
        + 99 others); Thu, 12 Jul 2018 22:30:11 -0400
Received: from hqemgate15.nvidia.com ([216.228.121.64]:1226 "EHLO
        hqemgate15.nvidia.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S2387972AbeGMCaL (ORCPT
        <rfc822;linux-kernel@vger.kernel.org>);
        Thu, 12 Jul 2018 22:30:11 -0400
Received: from hqpgpgate102.nvidia.com (Not Verified[216.228.121.13]) by hqemgate15.nvidia.com (using TLS: TLSv1, AES128-SHA)
        id <B5b480b9f0001>; Thu, 12 Jul 2018 19:17:03 -0700
Received: from HQMAIL105.nvidia.com ([172.20.161.6])
  by hqpgpgate102.nvidia.com (PGP Universal service);
  Thu, 12 Jul 2018 19:17:48 -0700
X-PGP-Universal: processed;
        by hqpgpgate102.nvidia.com on Thu, 12 Jul 2018 19:17:48 -0700
Received: from [10.2.167.205] (10.2.167.205) by HQMAIL105.nvidia.com
 (172.20.187.12) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Fri, 13 Jul
 2018 02:17:47 +0000
Subject: Re: [PATCH v2] tools/memory-model: Add extra ordering for locks and
 remove it for ordinary release/acquire
To:     Will Deacon <will.deacon@arm.com>,
        Peter Zijlstra <peterz@infradead.org>
CC:     Andrea Parri <andrea.parri@amarulasolutions.com>,
        Alan Stern <stern@rowland.harvard.edu>,
        "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>,
        LKMM Maintainers -- Akira Yokosawa <akiyks@gmail.com>,
        Boqun Feng <boqun.feng@gmail.com>,
        David Howells <dhowells@redhat.com>,
        Jade Alglave <j.alglave@ucl.ac.uk>,
        Luc Maranget <luc.maranget@inria.fr>,
        Nicholas Piggin <npiggin@gmail.com>,
        Kernel development list <linux-kernel@vger.kernel.org>
References: <Pine.LNX.4.44L0.1807091519180.2462-100000@iolanthe.rowland.org>
 <20180710093821.GA5414@andrea> <20180711094310.GA13963@arm.com>
 <20180711123421.GA9673@andrea>
 <20180712074040.GA4920@worktop.programming.kicks-ass.net>
 <20180712093432.GV2512@hirez.programming.kicks-ass.net>
 <20180712094510.GA23415@arm.com>
From:   Daniel Lustig <dlustig@nvidia.com>
Message-ID: <96aa1571-d9b9-9554-7017-d173e1a795e9@nvidia.com>
Date:   Thu, 12 Jul 2018 19:17:46 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101
 Thunderbird/52.9.1
MIME-Version: 1.0
In-Reply-To: <20180712094510.GA23415@arm.com>
X-Originating-IP: [10.2.167.205]
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: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On 7/12/2018 2:45 AM, Will Deacon wrote:
> On Thu, Jul 12, 2018 at 11:34:32AM +0200, Peter Zijlstra wrote:
>> On Thu, Jul 12, 2018 at 09:40:40AM +0200, Peter Zijlstra wrote:
>>> And I think if we raise atomic*_acquire() to require TSO (but ideally
>>> raise it to RCsc) we're there.
>>
>> To clarify, just the RmW-acquire. Things like atomic_read_acquire() can
>> stay smp_load_acquire() and be RCpc.
> 
> I don't have strong opinions about strengthening RmW atomics to TSO, so
> if it helps to unblock Alan's patch (which doesn't go near this!) then I'll
> go with it. The important part is that we continue to allow roach motel
> into the RmW for other accesses in the non-fully-ordered cases.
> 
> Daniel -- your AMO instructions are cool with this, right? It's just the
> fence-based implementations that will need help?
> 
> Will
Right, let me pull this part out of the overly-long response I just gave
on the thread with Linus :)

if we pair AMOs with AMOs, we get RCsc, and everything is fine.  If we
start mixing in fences (mostly because we don't currently have native
load-acquire or store-release opcodes), then that's when all the rest of the
complexity comes in.

Dan