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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id A2339CDB465 for ; Thu, 19 Oct 2023 17:00:06 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1345324AbjJSRAG (ORCPT ); Thu, 19 Oct 2023 13:00:06 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54810 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235462AbjJSRAE (ORCPT ); Thu, 19 Oct 2023 13:00:04 -0400 Received: from mail-ej1-x634.google.com (mail-ej1-x634.google.com [IPv6:2a00:1450:4864:20::634]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 6B58F9E for ; Thu, 19 Oct 2023 10:00:02 -0700 (PDT) Received: by mail-ej1-x634.google.com with SMTP id a640c23a62f3a-9becde9ea7bso224771066b.0 for ; Thu, 19 Oct 2023 10:00:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; t=1697734800; x=1698339600; darn=vger.kernel.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=Pp7DjBy4yEdH9XhZTLmenXL9Ia/EidVAE+FzX9SfFGw=; b=DgWkQhdmOTdcEy/Yv3wGRBig5iTeL8dva4ZMKQZsyEQX1iUx6Mk7cMGt/Bsj1So5u3 RaQU38deeAVY3msVX0thsgCN8oiEVP9ZFt5ALYzR6xf532j4dmXxQ6EhLPuOwSUA1k8V dxOXVZEn+7187txCn/+C+oH/UegywENf+g/wU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1697734800; x=1698339600; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=Pp7DjBy4yEdH9XhZTLmenXL9Ia/EidVAE+FzX9SfFGw=; b=XnDR6HJ6F7ADLNF9tvieRkwNaohkhmii/a2yBQu36mq/QClYF8ABYBKLuW1cLWN441 7g3hNrXHKzNGUe8rXNlT5TQaoD5z0QpfPV3e13IlfAHmDBEFTbCet8WMd+/e0gQtMKdV 5e0vwatpBmAaOv0lwiOqO5Fh6JLhHme9ccJw8Dzp6Q/Sa0f4f5LP1GWLzqCTr5OXQ6ql fm3/iE35aLWaQy48GknG4hz3qRRRSg78d0x5qv85iCLGQkQbTx1QGTa0mrAlgCx8v18G 4eqSp9SejmYNJs4b3zEfSxPY//vi4Z7mNzLRDu/x5A/VnlqxSbMu9302DU3W6Q1W/hVv sGcA== X-Gm-Message-State: AOJu0Yxt0qv37PeBl+5lklxqN/XyjIDISbVu6ZZpOFaGPsqlQJAfmW9b Gq9EeVyuAc8x4hmaO4FAReSPrs3XrClsis3SujTyU//+ X-Google-Smtp-Source: AGHT+IEyZazFBejfEDsIkCyyaGIg9k3bWrsdThli0851kyKHIquGL+W1zZJWunOU0K85C7YgBcFP2w== X-Received: by 2002:a17:906:c149:b0:9b2:cee1:1f82 with SMTP id dp9-20020a170906c14900b009b2cee11f82mr2093558ejc.7.1697734800647; Thu, 19 Oct 2023 10:00:00 -0700 (PDT) Received: from mail-ej1-f52.google.com (mail-ej1-f52.google.com. [209.85.218.52]) by smtp.gmail.com with ESMTPSA id a15-20020a170906684f00b00997d7aa59fasm3930534ejs.14.2023.10.19.09.59.59 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 19 Oct 2023 09:59:59 -0700 (PDT) Received: by mail-ej1-f52.google.com with SMTP id a640c23a62f3a-9adb9fa7200so224310866b.0 for ; Thu, 19 Oct 2023 09:59:59 -0700 (PDT) X-Received: by 2002:a17:907:7295:b0:9a9:f0e6:904e with SMTP id dt21-20020a170907729500b009a9f0e6904emr2171331ejc.16.1697734799075; Thu, 19 Oct 2023 09:59:59 -0700 (PDT) MIME-Version: 1.0 References: <20231010164234.140750-1-ubizjak@gmail.com> <0617BB2F-D08F-410F-A6EE-4135BB03863C@vmware.com> <7D77A452-E61E-4B8B-B49C-949E1C8E257C@vmware.com> <9F926586-20D9-4979-AB7A-71124BBAABD3@vmware.com> <3F9D776E-AD7E-4814-9E3C-508550AD9287@vmware.com> <28B9471C-4FB0-4AB0-81DD-4885C3645E95@vmware.com> In-Reply-To: From: Linus Torvalds Date: Thu, 19 Oct 2023 09:59:42 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v2 -tip] x86/percpu: Use C for arch_raw_cpu_ptr() To: Uros Bizjak Cc: peterz@infradead.org, Nadav Amit , "the arch/x86 maintainers" , Linux Kernel Mailing List , Andy Lutomirski , Brian Gerst , Denys Vlasenko , "H . Peter Anvin" , Thomas Gleixner , Josh Poimboeuf , Nick Desaulniers Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 19 Oct 2023 at 00:04, Uros Bizjak wrote: > > Let me explain how the compiler handles volatile. We're talking past each other. You are talking about the volatile *memory* ops, and the the difference that "raw" vs "this" would cause with and without the "volatile". While *I* am now convinced that the memory ops aren't even an option, because they will generate worse code, because pretty much all users use the "this" version (which would have to use volatile), Because if we just stick with inline asms, the need for "volatile" simply goes away. The existing volatile on those percpu inline asms is *wrong*. It's a historical mistake. And with just a plain non-volatile inline asm, the inline asm wins. It doesn't have the (bad) read-once behavior of a volatile memory op. And it also doesn't have the (horrible correctness issue) rematerialization behavior of a non-volatile memory op. A compiler that were to rematerializes an inline asm (instead of spilling) would be a bad joke. That's not an optimization, that's just a crazy bad compiler with a code generation bug. Linus