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 385B6CDB47E for ; Wed, 18 Oct 2023 18:27:13 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231223AbjJRS1N (ORCPT ); Wed, 18 Oct 2023 14:27:13 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47378 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230198AbjJRS1L (ORCPT ); Wed, 18 Oct 2023 14:27:11 -0400 Received: from mail-ed1-x52e.google.com (mail-ed1-x52e.google.com [IPv6:2a00:1450:4864:20::52e]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 29B98B6 for ; Wed, 18 Oct 2023 11:27:09 -0700 (PDT) Received: by mail-ed1-x52e.google.com with SMTP id 4fb4d7f45d1cf-53f6ccea1eeso1344881a12.3 for ; Wed, 18 Oct 2023 11:27:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1697653627; x=1698258427; darn=vger.kernel.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=5TU3G9xnPBOUL/P4ZcdOX0XkXjpSFEhyC5wq5582SnM=; b=TMYEoMLsISO0IFkzlgqc/lbx5XEjuV6aPXku6nAJkyrMAoFflgSWOqs1XwwfsSR6l1 BJbwe9/uVOai8pwlPZaXdtMM+jmko74YYMhn8+QjhZNn4psT1k2sjMl7dvP614Z4b6Yy C0y5OZYqclixmND8EFnajf7q05P0HBBf4O+CamqL7SoSN5xH/oXOlZHI1mwzAU5syVli 5lkPszhgjiMISeN+f8g0iugzwK9A4oKEBogJ0JUy/FcJtgZmACenfvXMzoLdEQ6OvORc 9Ad0UxJtfR9v+Gq+zo9+XVdLztGGX5JAXWYuwk/qEKSh+Equ3t7B/4jw2MKerR2gygCx u3dQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1697653627; x=1698258427; h=content-transfer-encoding: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=5TU3G9xnPBOUL/P4ZcdOX0XkXjpSFEhyC5wq5582SnM=; b=MNGjjvnkoF+sf+B9Vgx73L0nzS8CNp7yXcZPK+wYSq3XjuPgmiHvE0rS5DPSi1hnF2 i0vxz/SX18OvXk25jCAFRdLbk77v81UC14hDxNi0Z1QcD1ebhoWPs+EBds111k8b+ikV mp1ckrnBtvCGxerXLAwE3RL2TaZzAtRCPOQNrD6PczfFKtjAJCn3qtIPLl4CUZZDIYap Mp+8AmLUwBoTcf7wRGdSrxht9DozwxF5iWHFE3/g/o9bCssZviSSK0FFoUTQi1avyUem wMuo59SBqfmVXc9X0zTTALyLxrMmN7o//803h8dCG+Du318WAZSh97ixrlqupkNntaoA Jh4A== X-Gm-Message-State: AOJu0YzAi+wBgF2T1sD/sruCOipnHSP/FhR8uEZVEyOp3MqxQi/hnrIU ogYSAZsrtCBr2nVlLSBwtL0gUoesPmrcJ27lREI= X-Google-Smtp-Source: AGHT+IFNP+QoxuXvgtYoSxeneqZrVArFubCjaBD+uccVuMQo6gceoQZN6OdhGvjGXFWgNWRVejhrDKUEZMnq5q/5bkE= X-Received: by 2002:a50:9e48:0:b0:52d:212d:78e8 with SMTP id z66-20020a509e48000000b0052d212d78e8mr4064598ede.34.1697653627368; Wed, 18 Oct 2023 11:27:07 -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: Uros Bizjak Date: Wed, 18 Oct 2023 20:26:55 +0200 Message-ID: Subject: Re: [PATCH v2 -tip] x86/percpu: Use C for arch_raw_cpu_ptr() To: Linus Torvalds Cc: Nadav Amit , "the arch/x86 maintainers" , Linux Kernel Mailing List , Andy Lutomirski , Brian Gerst , Denys Vlasenko , "H . Peter Anvin" , Peter Zijlstra , Thomas Gleixner , Josh Poimboeuf , Nick Desaulniers Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Oct 18, 2023 at 8:16=E2=80=AFPM Linus Torvalds wrote: > > On Wed, 18 Oct 2023 at 11:08, Uros Bizjak wrote: > > > > But loads from non-const memory work like the above. > > Yes, I'm certainly ok with the move to use plain loads from __seg_gs > for the percpu accesses. If they didn't honor the memory clobber, we > could never use it at all. > > I was just saying that the 'const' alias trick isn't useful for > anything else than 'current', because everything else needs to at > least honor our existing barriers. FYI, smp_processor_id() is implemented as: #define __smp_processor_id() __this_cpu_read(pcpu_hot.cpu_number) where __this_* forces volatile access which disables CSE. *If* the variable is really stable, then it should use __raw_cpu_read. Both, __raw_* and __this_* were recently (tip/percpu branch) implemented for SEG_SUPPORT as: #define __raw_cpu_read(qual, pcp) \ ({ \ *(qual __my_cpu_type(pcp) *)__my_cpu_ptr(&(pcp)); \ }) where "qual" can be volatile. To enable smp_processor_id() optimization, it just needs to be moved from __this to __raw accessor. > (And yes, there's the other user of this_cpu_read_stable() - > 'top_of_stack', but as mentioned that doesn't really matter). Uros.