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 831C5C35FEA for ; Tue, 17 Sep 2024 07:12:56 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 1240F6B008A; Tue, 17 Sep 2024 03:12:56 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 0D5316B0092; Tue, 17 Sep 2024 03:12:56 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id EDEA36B0093; Tue, 17 Sep 2024 03:12:55 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id D10DC6B008A for ; Tue, 17 Sep 2024 03:12:55 -0400 (EDT) Received: from smtpin13.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 87475C0193 for ; Tue, 17 Sep 2024 07:12:55 +0000 (UTC) X-FDA: 82573363110.13.EC41647 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf16.hostedemail.com (Postfix) with ESMTP id C10BF18000E for ; Tue, 17 Sep 2024 07:12:53 +0000 (UTC) Authentication-Results: imf16.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=rbt1g37N; dmarc=pass (policy=quarantine) header.from=kernel.org; spf=pass (imf16.hostedemail.com: domain of will@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=will@kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1726557092; a=rsa-sha256; cv=none; b=05ZMJl7xtKe6rrHGXbjH13HA7LSp8dNj3i/oUvtyim/Av8X1YeV4pd30md/i1zA1z/PLAr QZoMA/cfRF9HaudMQLfRceEVeepIM/5H6c0epF1dKhQ1WczCp2PHmpqFsbRL+jJ5gIzD5M Mn5vgrifSFzFiYLc6i1BxSzfIMS4qQU= ARC-Authentication-Results: i=1; imf16.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=rbt1g37N; dmarc=pass (policy=quarantine) header.from=kernel.org; spf=pass (imf16.hostedemail.com: domain of will@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=will@kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1726557092; 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=ZOaOz4PXh6CKmoIij62EGMcw8JZ80tLFHlbr+TJamQs=; b=kkA89mUZHgsfhkseoFmTxtL9yyi2NMsKeC0xOrU6knjBWfKgsDrRtDfmFSxr/A+3QmHgPl mETXuIVQu6PRpTUzGzqwf+boIaxA9mM/I7Ohj3zZwoQXrynJmvfau3q4djKtKzPbSmDGVD SIgKLWG/ZIJLSXrrBIUq8Cw3avGK6+A= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id D7F365C0F76; Tue, 17 Sep 2024 07:12:48 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 264AAC4CEC6; Tue, 17 Sep 2024 07:12:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1726557172; bh=hgacHKFfwOa5El2HeDetZQZ0AkxJ6nRNh6t/Xie2Pm4=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=rbt1g37NEqrGSbdmS1XbUHYbqBqU8BT+ANrGbMK5ko2XPfVxK/AbAsiTK4WCHnX8I slITtFPqjcN3zcvVWRJOU5TY17zyHnNsXcsacXSJB3J7Q5yGt+Xnt9wK6QzAUyTLmS XDt+VDn/DIur7Uh5jwt4Sz/Zg+6/6ZvL3HezmTBfgyc0GEIupf1nr7SvTV7CrWDJWt sOOdSj13f4xKEkb4hYDqMhx8QNDFMNPVM+PvhAUDkXXJILKsxYT6sK9YEldGNQ8blX mjGH9gNVk/2uuFF+sd9UWKqw+oDH2ix6OOK8KhBybNaT5vr6HSYELs5obuU85NCz+m a70eJoZIVHogg== Date: Tue, 17 Sep 2024 08:12:46 +0100 From: Will Deacon To: cl@gentwo.org Cc: Thomas Gleixner , Catalin Marinas , Peter Zijlstra , Ingo Molnar , Waiman Long , Boqun Feng , Linus Torvalds , linux-mm@kvack.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-arch@vger.kernel.org Subject: Re: [PATCH v3] Avoid memory barrier in read_seqcount() through load acquire Message-ID: <20240917071246.GA27290@willie-the-truck> References: <20240912-seq_optimize-v3-1-8ee25e04dffa@gentwo.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20240912-seq_optimize-v3-1-8ee25e04dffa@gentwo.org> User-Agent: Mutt/1.10.1 (2018-07-13) X-Rspamd-Queue-Id: C10BF18000E X-Rspam-User: X-Rspamd-Server: rspam05 X-Stat-Signature: 3pontbckj9fjrzszcon63na713n5x9ak X-HE-Tag: 1726557173-685469 X-HE-Meta: U2FsdGVkX1+J2Js1UrG0I/AKKE/9Jdhj/BgtWWIPaju2Vw/Tb61ws5f6V+gom1BQ0t9qFyZjT2+7tT89rYAGXk705OoPj6y6hgGvlfxfxnA8YJh9KHNbr0rCR6qP8JFX4TnfuAtOo/P/SKaqb98Ug9dliH/E9dfghpfMRqZpIltbcJa2jPuclKMGLP+QtBHpdP0WwWlcZ5oRzkLNbB0QfWkSGzZz4xr2LZ+HpyByj8T+Y/dZnwwxlU2xtEnPi57nlzWN9z8i1kYfA5OR/CQvBYGXEmm03gLZOjlLMAxvzI7tiHWezdWGGb0kwaB6MVoaYf+8mIxd7/ZQd1VBLPhOIcY7LLXHi6sRK6MKLaVm8UMy0IMgy2yJ6cuxgAECITx1Kr9GuA1+dAbUWEn7SRbQFjLNolukSCzGlCoSCNrFC+kFaebcpuWWEiyWQY/5wb1s9QPZPZgLAAOphE7UXHhv9t6owonzaDjDbbtlfSIlJYqi+Bh+gW7ie7QpeXt+QGw1wVcJ/sJmJq1c0ZpumjRh0VuXnr0h7uKryXFXlZnh1AiUPNJTPff+6duyFXvRGtqA5S8mo5vw0xqlxS/Z0CHJfKQ4f6CPXjjGTYENpQ6fVzzqsJInNOagCiJoSmLcS/LJ9Cd48cvYtsAf857c2Epk3sx2uFyOCPTLUwMW1Qy4YB72acZU9YyUfJRLqzyNdwIyYGyyKJBxZEMRSHz+6e46JREJrngaHlCRARGsuZZ2q05WgGewu659rN/+vUQOf5e3kASkTHw6BomMJGvpb9pUcnJqtG9V/7hkLQqVxW6Cl9yFzIzCkpSQt2vwJMCVHKNuf6bbgVql+myxhNoU0BxXh5RpzIYbcnAfmPi/7yYiQAXNIpd11V0JMaJyZoBoIgDx8OwPwBtvrShQxnRxbh4xWN/QKLtW9tfcTzBdQyI2QJz/1CCQoT+anuVjGWhJoEcW1UGrX65TcUelMk0Wnac cGf/mNJV hS9zYcjZwHXc1NJVvwYqiweMGqllVvJJlg27Vncz8uYjR+BoqBOnIOFAHvvj5KLqkXCASmYWAD2K2XwZB/M2a2aSLO8pG1NF7oZBq308TmvTk0RneSWmHgE9Upn1s+fZ/wrgzJvnqYqGmVni68PVubMRUViX7RJgHNcZl9aqqd5wqLXmMWoP0+aEeLW7+R8mqNycKVg9tabnZS2KVxRGb9qNwie/O4FhlDe92TlJ01YISafKfuQoyhAoLjKBx5e8ru0OAvsSyV2+eaTlnudM8vlIDYQ1Kxkgik+0ApVFTVtE43N8JLmPigrtTYiSRRSMIO3J5VXm4obNhj6TPu8m44GyqmQ== 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: Hi Christoph, On Thu, Sep 12, 2024 at 03:44:08PM -0700, Christoph Lameter via B4 Relay wrote: > diff --git a/arch/Kconfig b/arch/Kconfig > index 975dd22a2dbd..3c270f496231 100644 > --- a/arch/Kconfig > +++ b/arch/Kconfig > @@ -1600,6 +1600,14 @@ config ARCH_HAS_KERNEL_FPU_SUPPORT > Architectures that select this option can run floating-point code in > the kernel, as described in Documentation/core-api/floating-point.rst. > > +config ARCH_HAS_ACQUIRE_RELEASE > + bool > + help > + Setting ARCH_HAS_ACQUIRE_RELEASE indicates that the architecture > + supports load acquire and release. Typically these are more effective > + than memory barriers. Code will prefer the use of load acquire and > + store release over memory barriers if this option is enabled. > + Unsurprisingly, I'd be in favour of making this unconditional rather than adding a new Kconfig option. Would that actually hurt any architectures where we care about the last few shreds of performance? > source "kernel/gcov/Kconfig" > > source "scripts/gcc-plugins/Kconfig" > diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig > index a2f8ff354ca6..19e34fff145f 100644 > --- a/arch/arm64/Kconfig > +++ b/arch/arm64/Kconfig > @@ -39,6 +39,7 @@ config ARM64 > select ARCH_HAS_PTE_DEVMAP > select ARCH_HAS_PTE_SPECIAL > select ARCH_HAS_HW_PTE_YOUNG > + select ARCH_HAS_ACQUIRE_RELEASE > select ARCH_HAS_SETUP_DMA_OPS > select ARCH_HAS_SET_DIRECT_MAP > select ARCH_HAS_SET_MEMORY > diff --git a/include/linux/seqlock.h b/include/linux/seqlock.h > index d90d8ee29d81..a3fe9ee8edef 100644 > --- a/include/linux/seqlock.h > +++ b/include/linux/seqlock.h > @@ -23,6 +23,13 @@ > > #include > > +#ifdef CONFIG_ARCH_HAS_ACQUIRE_RELEASE > +# define USE_LOAD_ACQUIRE true > +# define USE_COND_LOAD_ACQUIRE !IS_ENABLED(CONFIG_PREEMPT_RT) > +#else > +# define USE_LOAD_ACQUIRE false > +# define USE_COND_LOAD_ACQUIRE false > +#endif > /* > * The seqlock seqcount_t interface does not prescribe a precise sequence of > * read begin/retry/end. For readers, typically there is a call to > @@ -132,6 +139,17 @@ static inline void seqcount_lockdep_reader_access(const seqcount_t *s) > #define seqcount_rwlock_init(s, lock) seqcount_LOCKNAME_init(s, lock, rwlock) > #define seqcount_mutex_init(s, lock) seqcount_LOCKNAME_init(s, lock, mutex) > > +static __always_inline unsigned __seqprop_load_sequence(const seqcount_t *s, bool acquire) > +{ > + if (!acquire || !USE_LOAD_ACQUIRE) > + return READ_ONCE(s->sequence); > + > + if (USE_COND_LOAD_ACQUIRE) > + return smp_cond_load_acquire((unsigned int *)&s->sequence, (s->sequence & 1) == 0); This looks wrong to me. The conditional expression passed to smp_cond_load_acquire() should be written in terms of 'VAL', otherwise you're introducing an additional non-atomic access to the sequence counter. Will