Received: by 10.223.164.202 with SMTP id h10csp4923510wrb;
        Wed, 29 Nov 2017 14:20:00 -0800 (PST)
X-Google-Smtp-Source: AGs4zMZD4xdoWTySoD/x6IRmVAkU4q5vn0At6F2BE5xWyh0/1TFD24UahOwwOkIOcHn/+Va/9Ull
X-Received: by 10.98.192.202 with SMTP id g71mr4463626pfk.33.1511994000159;
        Wed, 29 Nov 2017 14:20:00 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; t=1511994000; cv=none;
        d=google.com; s=arc-20160816;
        b=o4nbz6E7xs6CelfzcPwzg8d/2BJfHA6G30qyozDuaI/cCNMSbA2aMevBjjkJkU1fIQ
         Eya8Cl6bHYHSIQCOOtinXy9yirDzcGlgb6XMlOjMpQV0GCV1W6BTl3EMLORgxJ++0srm
         a5Dp4t7Stf7KhMKB1v8Qc4ANaQKySrwvSpWJxAIrk2JM/dvQW8Dbq+T/AKa3h7HXjVAQ
         XC6Kthkdz9GsXPtGBcYGd+bZa81F/WPB8BnoNurJ8QrE09DuTgSKfW+CjJNpZZcDNo17
         1GQkPi3Lag8sWZmyHees+oGNlk5V+xVM00xCeQzpMelZra1qDz9NyQYbAt1BRhd0WjV6
         ITlw==
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=TtfNnV6XLA5//D1P0c9cP7nJhYboMbMmn1Cvkgu2QIs=;
        b=dlkFK1ICwCZ9isd+Vq0UR2Jo/b6t3xeRtdQ9t4DJ57XD/+lsUC+7MQfM/SL4zXPuXl
         Lz2HUjR/GJn39k8WIjOpRFNWiAczvadxdF34Rno4lisqJeojKXXqA+m2LGRi+t4zqZtV
         QiEy9fNhOqJGdBiND6siRDLxKvDROn04TNzjvKvXQDLCxFSCCQHEs/WYVWxPRhI1YNbN
         oA3uu2KxKxcRdkUvJiaT+rOBISFVdupyS2lI47eP8qKgc3uoVbivOSjazqILMWEyGnzm
         YcZ6NnHNMyg5Sidi4q9I2TwZnSkAqLXQgudkYoxYgNiQE451LgRbNn1BEwOsZDMlXanZ
         MvEA==
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 d126si2030549pfg.11.2017.11.29.14.19.45;
        Wed, 29 Nov 2017 14:20:00 -0800 (PST)
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 S1752594AbdK2WSu (ORCPT <rfc822;shmalave.kernel@gmail.com>
        + 99 others); Wed, 29 Nov 2017 17:18:50 -0500
Received: from hqemgate14.nvidia.com ([216.228.121.143]:6527 "EHLO
        hqemgate14.nvidia.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1751660AbdK2WSt (ORCPT
        <rfc822;linux-kernel@vger.kernel.org>);
        Wed, 29 Nov 2017 17:18:49 -0500
Received: from hqpgpgate102.nvidia.com (Not Verified[216.228.121.13]) by hqemgate14.nvidia.com
        id <B5a1f323c0001>; Wed, 29 Nov 2017 14:18:36 -0800
Received: from HQMAIL105.nvidia.com ([172.20.161.6])
  by hqpgpgate102.nvidia.com (PGP Universal service);
  Wed, 29 Nov 2017 14:19:30 -0800
X-PGP-Universal: processed;
        by hqpgpgate102.nvidia.com on Wed, 29 Nov 2017 14:19:30 -0800
Received: from [10.2.175.48] (10.2.175.48) by HQMAIL105.nvidia.com
 (172.20.187.12) with Microsoft SMTP Server (TLS) id 15.0.1293.2; Wed, 29 Nov
 2017 22:18:48 +0000
Subject: Re: Unlock-lock questions and the Linux Kernel Memory Model
To:     "paulmck@linux.vnet.ibm.com" <paulmck@linux.vnet.ibm.com>,
        Alan Stern <stern@rowland.harvard.edu>
CC:     Peter Zijlstra <peterz@infradead.org>,
        Andrea Parri <parri.andrea@gmail.com>,
        Luc Maranget <luc.maranget@inria.fr>,
        Jade Alglave <j.alglave@ucl.ac.uk>,
        Boqun Feng <boqun.feng@gmail.com>,
        Nicholas Piggin <npiggin@gmail.com>,
        Will Deacon <will.deacon@arm.com>,
        David Howells <dhowells@redhat.com>,
        Palmer Dabbelt <palmer@dabbelt.com>,
        Kernel development list <linux-kernel@vger.kernel.org>
References: <20171129194602.6zmjj7z5ih4ri25h@hirez.programming.kicks-ass.net>
 <Pine.LNX.4.44L0.1711291450070.1369-100000@iolanthe.rowland.org>
 <20171129204220.GH3624@linux.vnet.ibm.com>
From:   Daniel Lustig <dlustig@nvidia.com>
Message-ID: <6b068a40-75bb-4152-b1ec-9ef3beacbdd5@nvidia.com>
Date:   Wed, 29 Nov 2017 14:18:48 -0800
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101
 Thunderbird/52.5.0
MIME-Version: 1.0
In-Reply-To: <20171129204220.GH3624@linux.vnet.ibm.com>
X-Originating-IP: [10.2.175.48]
X-ClientProxiedBy: HQMAIL108.nvidia.com (172.18.146.13) 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 11/29/2017 12:42 PM, Paul E. McKenney wrote:
> On Wed, Nov 29, 2017 at 02:53:06PM -0500, Alan Stern wrote:
>> On Wed, 29 Nov 2017, Peter Zijlstra wrote:
>>
>>> On Wed, Nov 29, 2017 at 11:04:53AM -0800, Daniel Lustig wrote:
>>>
>>>> While we're here, let me ask about another test which isn't directly
>>>> about unlock/lock but which is still somewhat related to this
>>>> discussion:
>>>>
>>>> "MP+wmb+xchg-acq" (or some such)
>>>>
>>>> {}
>>>>
>>>> P0(int *x, int *y)
>>>> {
>>>>         WRITE_ONCE(*x, 1);
>>>>         smp_wmb();
>>>>         WRITE_ONCE(*y, 1);
>>>> }
>>>>
>>>> P1(int *x, int *y)
>>>> {
>>>>         r1 = atomic_xchg_relaxed(y, 2);
>>>>         r2 = smp_load_acquire(y);
>>>>         r3 = READ_ONCE(*x);
>>>> }
>>>>
>>>> exists (1:r1=1 /\ 1:r2=2 /\ 1:r3=0)
>>>>
>>>> C/C++ would call the atomic_xchg_relaxed part of a release sequence
>>>> and hence would forbid this outcome.
>>>
>>> That's just weird. Either its _relaxed, or its _release. Making _relaxed
>>> mean _release is just daft.
>>
>> The C11 memory model specifically allows atomic operations to be 
>> interspersed within a release sequence.  But it doesn't say why.
> 
> The use case put forward within the committee is for atomic quantities
> with mode bits.  The most frequent has the atomic quantity having
> lock-like properties, in which case you don't want to lose the ordering
> effects of the lock handoff just because a mode bit got set or cleared.
> Some claim to actually use something like this, but details have not
> been forthcoming.
> 
> I confess to being a bit skeptical.  If the mode changes are infrequent,
> the update could just as well be ordered.

Aren't reference counting implementations which use memory_order_relaxed
for incrementing the count another important use case?  Specifically,
the synchronization between a memory_order_release decrement and the
eventual memory_order_acquire/consume free shouldn't be interrupted by
other (relaxed) increments and (release-only) decrements that happen in
between.  At least that's my understanding of this use case.  I wasn't
there when the C/C++ committee decided this.

> That said, Daniel, the C++ memory model really does require that the
> above litmus test be forbidden, my denigration of it notwithstanding.

Yes I agree, that's why I'm curious what the Linux memory model has
in mind here :)

Dan

> 							Thanx, Paul
> 

From 1585434595230387843@xxx Wed Nov 29 20:44:13 +0000 2017
X-GM-THRID: 1585255508732072548
X-Gmail-Labels: Inbox,Category Forums,HistoricalUnread