From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on archive.lwn.net X-Spam-Level: X-Spam-Status: No, score=-5.8 required=5.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RCVD_IN_DNSWL_HI autolearn=unavailable autolearn_force=no version=3.4.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by archive.lwn.net (Postfix) with ESMTP id 5BE497DF8F for ; Mon, 25 Jun 2018 15:44:31 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751658AbeFYPoS (ORCPT ); Mon, 25 Jun 2018 11:44:18 -0400 Received: from hqemgate15.nvidia.com ([216.228.121.64]:1098 "EHLO hqemgate15.nvidia.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751381AbeFYPoR (ORCPT ); Mon, 25 Jun 2018 11:44:17 -0400 Received: from hqpgpgate101.nvidia.com (Not Verified[216.228.121.13]) by hqemgate15.nvidia.com (using TLS: TLSv1, AES128-SHA) id ; Mon, 25 Jun 2018 08:43:48 -0700 Received: from HQMAIL105.nvidia.com ([172.20.161.6]) by hqpgpgate101.nvidia.com (PGP Universal service); Mon, 25 Jun 2018 08:44:16 -0700 X-PGP-Universal: processed; by hqpgpgate101.nvidia.com on Mon, 25 Jun 2018 08:44:16 -0700 Received: from [10.2.161.48] (10.2.161.48) by HQMAIL105.nvidia.com (172.20.187.12) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Mon, 25 Jun 2018 15:44:15 +0000 Subject: Re: [PATCH] doc: Update wake_up() & co. memory-barrier guarantees To: Andrea Parri , Peter Zijlstra CC: , , Alan Stern , Will Deacon , Boqun Feng , Nicholas Piggin , David Howells , Jade Alglave , Luc Maranget , "Paul E. McKenney" , Akira Yokosawa , Jonathan Corbet , Ingo Molnar , Randy Dunlap References: <1529918258-7295-1-git-send-email-andrea.parri@amarulasolutions.com> <20180625095031.GX2494@hirez.programming.kicks-ass.net> <20180625105618.GA12676@andrea> <20180625123121.GY2494@hirez.programming.kicks-ass.net> <20180625131643.GA15126@andrea> <20180625141830.GC2494@hirez.programming.kicks-ass.net> <20180625145611.GA16333@andrea> From: Daniel Lustig Message-ID: Date: Mon, 25 Jun 2018 08:44:14 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <20180625145611.GA16333@andrea> X-Originating-IP: [10.2.161.48] 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-doc-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-doc@vger.kernel.org On 6/25/2018 7:56 AM, Andrea Parri wrote: > On Mon, Jun 25, 2018 at 04:18:30PM +0200, Peter Zijlstra wrote: >> On Mon, Jun 25, 2018 at 03:16:43PM +0200, Andrea Parri wrote: >>>>> A concrete example being the store-buffering pattern reported in [1]. >>>> >>>> Well, that example only needs a store->load barrier. It so happens >>>> smp_mb() is the only one actually doing that, but imagine we had a >>>> weaker barrier that did just that, one that did not imply the full >>>> transitivity smp_mb() does. >>>> >>>> Then the example from [1] could use that weaker thing. >>> >>> Absolutely (and that would be "fence w,r" on RISC-V, IIUC). >> >> Ah cute. What is the transitivity model of those "fence" instructions? I >> see their smp_mb() is "fence rw,rw" and smp_mb() must be RSsc. Otoh >> their smp_wmb() is "fence w,w" which is only only required to be RCpc. >> >> So what does RISC-V do for "w,w" and "w,r" like things? > > I'd defer to Daniel (in Cc:) for this ;-) I simply checked the SB pattern > plus w,r fences against the following models: > > http://www.cl.cam.ac.uk/~sf502/regressions/rmem/ > http://moscova.inria.fr/~maranget/cats7/riscv/ > First off, the latest RISC-V spec is here, in case anyone hasn't seen it: https://github.com/riscv/riscv-isa-manual. It's all public now, fortunately. There's a PDF link at the bottom of that page too. The spec now has proposed Linux mappings (not all of which have actually made it upstream...) in Appendix A.5 as well. We'd welcome general feedback on those. Now to the question above: RISC-V is (other-)multi-copy-atomic, so I don't think transitivity should be an issue here. We do have a "fence w,r", but we decided to warn against actually using it for a few reasons: 1) lack of known common use cases :), 2) IIRC there was some corner case discrepancy between the axiomatic and operational models if we allowed it, and 3) in practice, it's already both expensive enough and obscure enough that many or most implementations will simply just treat it as "fence rw,rw" anyway. So, in theory, "fence w,r" should be enough to prevent SB-like patterns. It's just not yet clear that it's a big enough win that it's worth creating a new fence macro for it, or pulling the current RISC-V recommendation against its use. What do you all think? Are there other known use cases where you really do want a "fence w,r" that's intentionally not also something stronger? How common would the pattern be? Dan -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html