From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755325AbbKDEnY (ORCPT ); Tue, 3 Nov 2015 23:43:24 -0500 Received: from mail-ig0-f179.google.com ([209.85.213.179]:32813 "EHLO mail-ig0-f179.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750806AbbKDEnW convert rfc822-to-8bit (ORCPT ); Tue, 3 Nov 2015 23:43:22 -0500 MIME-Version: 1.0 In-Reply-To: <20151104035700.GN29027@linux.vnet.ibm.com> References: <20151102132901.157178466@infradead.org> <20151102134941.005198372@infradead.org> <20151102183659.GN29657@arm.com> <20151103015743.GC29027@linux.vnet.ibm.com> <20151104035700.GN29027@linux.vnet.ibm.com> Date: Tue, 3 Nov 2015 20:43:22 -0800 X-Google-Sender-Auth: WSym0grrXvJY2yTknCKEYSTfDAA Message-ID: Subject: Re: [PATCH 4/4] locking: Introduce smp_cond_acquire() From: Linus Torvalds To: Paul McKenney Cc: Will Deacon , Peter Zijlstra , Ingo Molnar , Oleg Nesterov , Linux Kernel Mailing List , boqun.feng@gmail.com, Jonathan Corbet , Michal Hocko , David Howells Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Nov 3, 2015 at 7:57 PM, Paul E. McKenney wrote: > > Thank you, and yes, it clearly states that read-to-write dependencies > are ordered. Well, I wouldn't say that it's exactly "clear". The fact that they explicitly say "Note that the DP relation does not directly impose a BEFORE (⇐) ordering between accesses u and v" makes it all clear as mud. They *then* go on to talk about how the DP relationship *together* with the odd "is source of" ordering (which in turn is defined in terms of BEFORE ordering) cannot have cycles. I have no idea why they do it that way, but the reason seems to be that they wanted to make "BEFORE" be purely about barriers and accesses, and make the other orderings be described separately. So the "BEFORE" ordering is used to define how memory must act, which is then used as a basis for that storage definition and the "is source of" thing. But none of that seems to make much sense to a *user*. The fact that they seem to equate "BEFORE" with "Processor Issue Constraints" also makes me think that the whole logic was written by a CPU designer, and part of why they document it that way is that the CPU designer literally thought of "can I issue this access" as being very different from "is there some inherent ordering that just results from issues outside of my design". I really don't know. That whole series of memory ordering rules makes my head hurt. But I do think the only thing that matters in the end is that they do have that DP relationship between reads and subsequently dependent writes, but basically not for *any* other relationship. So on alpha read-vs-read, write-vs-later-read, and write-vs-write all have to have memory barriers, unless the accesses physically overlap. Linus