From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id DD779C433EF for ; Wed, 8 Sep 2021 16:09:03 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id AB91C60C51 for ; Wed, 8 Sep 2021 16:09:03 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1346618AbhIHQKK (ORCPT ); Wed, 8 Sep 2021 12:10:10 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54754 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232904AbhIHQKI (ORCPT ); Wed, 8 Sep 2021 12:10:08 -0400 Received: from mail-lj1-x232.google.com (mail-lj1-x232.google.com [IPv6:2a00:1450:4864:20::232]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 0F491C061757 for ; Wed, 8 Sep 2021 09:09:00 -0700 (PDT) Received: by mail-lj1-x232.google.com with SMTP id m4so4382214ljq.8 for ; Wed, 08 Sep 2021 09:08:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=F5ZeFAknLDpJj0gufvdFHOmCevevfl6tESN6kJ6gAYQ=; b=K7yBmZ5ODUwzJy0G0jcYOAQOAvzjZ2K4Y7BSVXC/PKjsSnt1W/esVP6NG0CrPEqZLv vl4EG3Oho6nNuiO8w8cWwRpynP/MON/EPcKbZHzGYWwDVVwQZqCDcHY5KbbkKxwnRGzQ FQmC6QIVNuaqe/2ky5dtaOZcTd7jTkqvfEY6Y= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=F5ZeFAknLDpJj0gufvdFHOmCevevfl6tESN6kJ6gAYQ=; b=RDTLA/BF8E7FqLf9nTX3d0n5ZiCHNUCFBYrskC/zA5Y72OAoxtryf7B6tF/LLew/jB SB3NMvKdiCEgVenVmL7BDDY6XKUHWGvPECsrFzh/ZnJ4AUN3XvwppUDi3ypmey2X5sVV GWN9SilDrce5c8y58Pr04TG68dGACRa4Gcd42xcO3LaBeXEokitYtrg8jRTMWTS74BZy LUE+gLzHtE+GukqzKzxBs2wtnAsrFYX01P3yVfTzEsRjrNA67+4dMOoQlwZmXxKOGhao xp3Ov+83v4wYLl3ED59UzJ4cq8hpjWl/R0UFThAOpEjMBSuzbS1bBhPx1RkpF0vRCAnH 84Pw== X-Gm-Message-State: AOAM532FTwBUhvQAmdXCYZyOsIZujNUDVw48CZ69o+ukp6WkwDRl8K0+ ikWPACx4fz+B1WgAdQFq1qyO4cfBjdD1cCb+nCw= X-Google-Smtp-Source: ABdhPJx9KJbZ0+NecyAisOYvOC47If0Pcs/vkuFwREOz3TT0mu6rqjeufnW+bkcHAQtUs87ZrDZE7w== X-Received: by 2002:a05:651c:385:: with SMTP id e5mr3351151ljp.35.1631117335494; Wed, 08 Sep 2021 09:08:55 -0700 (PDT) Received: from mail-lj1-f178.google.com (mail-lj1-f178.google.com. [209.85.208.178]) by smtp.gmail.com with ESMTPSA id z1sm227129lfu.222.2021.09.08.09.08.50 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 08 Sep 2021 09:08:51 -0700 (PDT) Received: by mail-lj1-f178.google.com with SMTP id g14so4389525ljk.5 for ; Wed, 08 Sep 2021 09:08:50 -0700 (PDT) X-Received: by 2002:a2e:8107:: with SMTP id d7mr3580653ljg.68.1631117329470; Wed, 08 Sep 2021 09:08:49 -0700 (PDT) MIME-Version: 1.0 References: <20180926182920.27644-2-paulmck@linux.ibm.com> <20210908144217.GA603644@rowland.harvard.edu> In-Reply-To: <20210908144217.GA603644@rowland.harvard.edu> From: Linus Torvalds Date: Wed, 8 Sep 2021 09:08:33 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [tip:locking/core] tools/memory-model: Add extra ordering for locks and remove it for ordinary release/acquire To: Alan Stern Cc: Peter Zijlstra , Alexander Shishkin , Peter Anvin , Andrea Parri , Ingo Molnar , "Paul E. McKenney" , Vince Weaver , Thomas Gleixner , Jiri Olsa , Arnaldo Carvalho de Melo , Linux Kernel Mailing List , Stephane Eranian , Will Deacon , linux-tip-commits@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Sep 8, 2021 at 7:42 AM Alan Stern wrote: > > there is no reason _in theory_ why a CPU shouldn't reorder and interleave > the operations to get: I agree about the theory part. But I think the LKMM should be the strongest ordering that is reasonable. And it should take common architecture behavior into account. IOW, if there is some rare architecture where the above can happen, but no common sane one allows it in practice, we should strive to make the LKMM the _stronger_ one. We sure as hell shouldn't say "RISC-V is potentially very weakly ordered, so we'll allow that weak ordering". Because overly weak ordering only causes problems for others. And the performance arguments for it have historically been garbage anyway. See the pain powerpc goes through because of bad ordering (and even more so alpha), and see how arm actually strengthened their ordering to make everybody happier. So if this is purely a RISC-V thing, then I think it's entirely reasonable to spin_unlock(&r); spin_lock(&s); cannot be reordered. Strict specifications are not a bad thing, and weak memory ordering is not inherently good. Linus