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 kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 8ECE0CDD541 for ; Wed, 18 Sep 2024 15:22:58 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 08BEE6B008A; Wed, 18 Sep 2024 11:22:58 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 03C026B009B; Wed, 18 Sep 2024 11:22:57 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E452E6B009C; Wed, 18 Sep 2024 11:22:57 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id C68106B008A for ; Wed, 18 Sep 2024 11:22:57 -0400 (EDT) Received: from smtpin05.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 3A79AAA0A2 for ; Wed, 18 Sep 2024 15:22:57 +0000 (UTC) X-FDA: 82578226794.05.19D2EEB Received: from mail-ot1-f50.google.com (mail-ot1-f50.google.com [209.85.210.50]) by imf26.hostedemail.com (Postfix) with ESMTP id 32F00140002 for ; Wed, 18 Sep 2024 15:22:54 +0000 (UTC) Authentication-Results: imf26.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=google header.b=PU8L33Vo; spf=pass (imf26.hostedemail.com: domain of torvalds@linuxfoundation.org designates 209.85.210.50 as permitted sender) smtp.mailfrom=torvalds@linuxfoundation.org; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1726672826; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=lCft1bt8+wTXWG4Mppm6Hwf7BdZO6lyQJ2NgHw2gpEM=; b=fC7iuIfVsCqq+zNPrSSGs66RbfFU7ntj5cHJgWWEBGCGgzzRZkY3UXitkOCcXgzbuauxVw sT7ZaR/edk0yosq8poaOxDth/kgJ6ovxMfTD7jZca1P0lZMYVINgwgdZbLLZYXtj0IBKBX MpIKLYkMiyW5vLfZt/AaMAuhHtlTk3g= ARC-Authentication-Results: i=1; imf26.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=google header.b=PU8L33Vo; spf=pass (imf26.hostedemail.com: domain of torvalds@linuxfoundation.org designates 209.85.210.50 as permitted sender) smtp.mailfrom=torvalds@linuxfoundation.org; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1726672826; a=rsa-sha256; cv=none; b=0BkiCojgPkhirShbU8A45Qq/zlHe54Zm8jYeURr7ndgYaxH2fXQqxV3pm5/DCpleGaUnhb nq4ii0nTj8HOwT8Hlb59JHMFLAGTi5QV0oI1fG2oY7xu1/X5BFY7pupccKc5ndPM+NFdm0 jGvEFclQku1/8Jbs3/YqxfMA6gBod2Q= Received: by mail-ot1-f50.google.com with SMTP id 46e09a7af769-71100987d1cso3338770a34.2 for ; Wed, 18 Sep 2024 08:22:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; t=1726672974; x=1727277774; darn=kvack.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=lCft1bt8+wTXWG4Mppm6Hwf7BdZO6lyQJ2NgHw2gpEM=; b=PU8L33VoMaLUy+p5b/P7pTxmiYCrKS9vrrqeLhJpZqLVeJatc8satEFv83PNr4nEmp OVZrDXUBUc9c5eImNgbbchhyndVlmIWkPFt08yn2h/r362lBST5cWBAeOpSSteXcCErk J7/E44M6Uuj5MaKtFJo8XWgdXr0GTy0gnOqeE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1726672974; x=1727277774; 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=lCft1bt8+wTXWG4Mppm6Hwf7BdZO6lyQJ2NgHw2gpEM=; b=moJjJy665zBBXi/GNPWGn6/D5YYhc2tr5piN6H83PJYUbEFZaGITuJTZM50EaF+6v4 CJcjIwJjKvFnC1t1rYUdkjFmccHhvQSlKJh42naK/8ck+F2VcDwSBpuJdyq9xlPn/1mW yz4MkxPfiX9PtERaYA7MGRIv2+5bPDVApz6D3zAMznOmpfJRXTbUzLibc4d7XlQOl+Jy oQalufFVrgT6UgGyjXAhKdx4ROxtJ/cPRtOUTHWeXeVtqW4sIMvBW29aPra4tlNeFBw/ SNM3sVDlz9oenH4NQMbnFWb4EzbEOPrFsgQftPlj6oqOprHTE9HBG+tKZqT5kHOnyZJC XjxQ== X-Forwarded-Encrypted: i=1; AJvYcCX/VyrZfPWydzTpPwzJx6Imzijvvu2Uqb6j0Q5ipI9D5mmZTIBc2baCFmord+m+4zEHgv1NOUVmYA==@kvack.org X-Gm-Message-State: AOJu0YxXyVulHc+kV7cCCF1l/UupjvvyzBA7r4F7YfMH+Y9u1J5kp4QM UWLE3bK0B+ucXdmVuy5lbd1MwReD3mLlV7Ua77SVEkTvlxc/Gu/iJnp9yVeuv/asjNCbdqDw/7n 5R4bTuw== X-Google-Smtp-Source: AGHT+IHqZ3zTGEXfrqHVMlMRoEEX2j06cQ2puEpQHoWLIUdk4JbdF8DkLbrctSyvyrej9b9QFTZwRw== X-Received: by 2002:a05:6830:63cc:b0:710:faa3:d89 with SMTP id 46e09a7af769-71116bebb97mr10840609a34.6.1726672973861; Wed, 18 Sep 2024 08:22:53 -0700 (PDT) Received: from mail-vk1-f172.google.com (mail-vk1-f172.google.com. [209.85.221.172]) by smtp.gmail.com with ESMTPSA id ada2fe7eead31-49e6b11d3e5sm1242295137.3.2024.09.18.08.22.52 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 18 Sep 2024 08:22:53 -0700 (PDT) Received: by mail-vk1-f172.google.com with SMTP id 71dfb90a1353d-501274e2c29so1650395e0c.3 for ; Wed, 18 Sep 2024 08:22:52 -0700 (PDT) X-Forwarded-Encrypted: i=1; AJvYcCXrPZmb9aQkP+vzIN1GXfApa8EUQikHYr9eIY7cmf8WOUr7kaN4C8L9P918mAkL/lJwtJWpOWw8cA==@kvack.org X-Received: by 2002:a05:6122:310c:b0:501:be30:2abf with SMTP id 71dfb90a1353d-50344b63a4dmr13070691e0c.1.1726672972559; Wed, 18 Sep 2024 08:22:52 -0700 (PDT) MIME-Version: 1.0 References: <20240912-seq_optimize-v3-1-8ee25e04dffa@gentwo.org> <20240917071246.GA27290@willie-the-truck> <4b546151-d5e1-22a3-a6d5-167a82c5724d@gentwo.org> In-Reply-To: <4b546151-d5e1-22a3-a6d5-167a82c5724d@gentwo.org> From: Linus Torvalds Date: Wed, 18 Sep 2024 17:22:17 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v3] Avoid memory barrier in read_seqcount() through load acquire To: "Christoph Lameter (Ampere)" Cc: Will Deacon , Thomas Gleixner , Catalin Marinas , Peter Zijlstra , Ingo Molnar , Waiman Long , Boqun Feng , linux-mm@kvack.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-arch@vger.kernel.org Content-Type: text/plain; charset="UTF-8" X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 32F00140002 X-Stat-Signature: wm5a3uuqxtfhc6ubaq7igx5fh7jgmdex X-Rspam-User: X-HE-Tag: 1726672974-440930 X-HE-Meta: U2FsdGVkX1+gqn/yiiifLgJmc+6C/ER/mnCS2T96FlZ3adlIw3Y+xHWdzNXhRbYIGPzr29xMSPz9vBHAsTX1ffNpXrsEO6AHA/D1x3z7LJlYLAvrn+GUIkGb/3V13U3tmjsPHLvekKbBkCOzYn3wAIUy3thclkA0sJX0Ai5Ygf971Pf9NpmN1jmtLj4HtLUWPdlyi0S3BRxwzIYfTZajiTrisAPe4FVogALh39SyeXoQHrbDQVZEi0XBkziNUw3Y0xMSeBetZmezlmqEUsblxckGLSj18/lMlvhm/6k1bd0b6HXz0DRhhdg2P/ZpDu2+8NdWZskYfmYHj2hJRCweUlrE+YaHe/bKeexl1VcHi8I0DDGFKMh8wUkJuzygjfxq9grD53n8LeaPqwVFJChCkonDUPvjhTYJAZ3gUJPsiNSXmXauAMek+n4SrwqrZkpKNImz+lT1Zf4ZX0OyrMNkaj/QwFUycZytXtAXEB3z/obJD45rUzyyCEuZIvONSyn5xZ0w+vgLbhS+ekbNcszl+qKhnZDeUa6JqQ40GdlHORHMpdOnVUfS4ctg1r7L+Nb/cFGynUM6AbTDIHg4MWqzXFQKLDV6a1dmV7/p8z2p9zrlN5rESfIsNhKAlK5Fgs14LnDfhBCdj7Yz8oK7tfHDe71gHoSMlQjFodo0X0zxbMorKgiAilIeidnp8CcO48GcHrZiG6790wNGsAkH+4GwqFg/9aNHadN38KxAgkddGKLrpQChFn393FhlUPKfj28iw/Bb8fk5dcZ61Cd5VY7VVdMjvaRxCOIrz/7cMgZ3ZD0S9Y6CvQmH3P+N0Vih919x74Rkn5WcQqjHqqr+OG4cqzztn2ILy/kzjRXAdcLm4P0K4cUX5HgTvfWcWrfwdig5re54CBn39t40ob98wqgOrbbDFsSLdbq8NsC1iTXctnPvkQYwGAH2SXRFHMomsxTsK8yOnr6U+nf8ZudVlD+ xgNjtwa9 jlB5YaQNKLJbyzWIn3HXVYwboIFkWSeEdXWcHj+Yi7Dzsb2Hr0dsPlTQRVxWEZ352zKDtty5W+SSoYIZ8D5Wl+TdM8z5vzocJiCe+x98iSVm+Zy/lMubXR+Gg4mjx63mYJYKEXMIaK436Y4BeLGXZl+NqUaIMVdsCWeP5Gr2EkNHjVD/zKnFbVDx1er9dJaACtaXRLsDh/APQU4ufDyIcyN6YlPO8vciiz15KVoJOLmKl3ZHRhJ3XB7lp2sapZRSQn9qWMH+9LplODa+7c06WQPOI9jPMl/SLzRf1TcJTS/q7EWLvXMq+qdI4bjdqWeOm8YUlRUaNH740SWSVZgq0yW7aCiemVeUXsOpQ4FC2XpxWUZb87wnEvyZGuf6k8G3+763w0ZIn11o9rCChc8hGHxJyUMNbYiJ0jYEPuhK63oqYu0q/7URDw17GHvQyRvOGUkDwEM95xGzRb2aIN9A7MY5vcHVA3Inl9zE7HwFfrC74TfWYbrYYtufWyQ9SY/4CmjSoRH0W8McR2+8ksgyCNP+U1IZYAis+S/HWM9kadSKGPkItaCbALk/11pFut132QMy4EZPIh+EZ9nrPt1s2uvrwkl836QLrDk1J0I1Grrst2di9E3op++zPUcqCK1oecCEpLo/5+TAkKeIB/+Xfbq/u55V+C6pDKX/B X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Wed, 18 Sept 2024 at 13:15, Christoph Lameter (Ampere) wrote: > > Other arches do not have acquire / release and will create additional > barriers in the fallback implementation of smp_load_acquire. So it needs > to be an arch config option. Actually, I looked at a few cases, and it doesn't really seem to be true. For example, powerpc doesn't have a "native" acquire model, but both smp_load_acquire() and smp_rmb() end up being LWSYNC after the load (which in the good case is a "lwsync" instruction, in bad case it's a heavier "sync" instruction on older cores, but the point is that it's the same thing for smp_rmb() and for smp_load_acquire()). So on powerpc, smp_load_acquire() isn't any better than "READ_ONCE()+smp_rmb()", but it also isn't any worse. And at least alpha is the same - it doesn't have smp_load_acquire(), and it falls back on a full memory barrier for that case - but that's what smp_rmb() is too. However, because READ_ONCE() on alpha already contains a smp_mb(), it turns out that on alpha having "READ_ONCE + smp_rmb()" actually results in *two* barriers, while a "smp_load_acquire()" is just one. And obviously technically x86 doesn't have explicit acquire, but with every load being an acquire, it's a no-op either way. So on at least three very different architectures, smp_load_acquire() is at least no worse than READ_ONCE() followed by a smp_rmb(). And on alpha and arm64, it's better. So it does look like making it conditional doesn't actually buy us anything. We might as well just unconditionally use the smp_load_acquire() over "READ_ONCE+smp_rmb". Other random architectures from a quick look: RISC-V technically turns smp_rmb() into a "fence r,r", while a smp_load_acquire() ends up being a "fence r,rw", so technically the fences are different. But honestly, any microarchitecture that makes those two be different is just crazy garbage (there's never any valid reason to move later writes up before earlier reads). Loongarch has acquire and is better off with it. parisc has acquire and is better off with it. s390 and sparc64 are like x86, in that it's just a build barrier either way. End result: let's just simplify the patch and make it entirely unconditional. Linus