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 A75CFCCD19D for ; Wed, 18 Sep 2024 11:15:44 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 126C66B0082; Wed, 18 Sep 2024 07:15:44 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 0B01D6B0083; Wed, 18 Sep 2024 07:15:44 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E6BF26B0085; Wed, 18 Sep 2024 07:15:43 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id C81AD6B0082 for ; Wed, 18 Sep 2024 07:15:43 -0400 (EDT) Received: from smtpin06.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 7362F1C42DF for ; Wed, 18 Sep 2024 11:15:43 +0000 (UTC) X-FDA: 82577603766.06.DC03197 Received: from gentwo.org (gentwo.org [62.72.0.81]) by imf02.hostedemail.com (Postfix) with ESMTP id C44A280007 for ; Wed, 18 Sep 2024 11:15:40 +0000 (UTC) Authentication-Results: imf02.hostedemail.com; dkim=pass header.d=gentwo.org header.s=default header.b=RnYf2xIj; spf=pass (imf02.hostedemail.com: domain of cl@gentwo.org designates 62.72.0.81 as permitted sender) smtp.mailfrom=cl@gentwo.org; dmarc=pass (policy=reject) header.from=gentwo.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1726658084; 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=Rl3Suv9Gr0inplGz8jcD4PSr30+237FWTUImYGXvpRo=; b=GyXhMg08M3xYbPhuuOFW8ZbzIt1aZh+kP+Vb7YUZQnk3eLkIwPTDXJJKonU4/N1QXPJ7DH 65Bb/sF+o/1XWSPgaz2raWt9cCMyEzHrc2TfOWQ3YjNakSK/YJJuwpnf41KQRaodqP2wM7 UCjY3yfcifFQ3Tvw59wF97rhsgVbooc= ARC-Authentication-Results: i=1; imf02.hostedemail.com; dkim=pass header.d=gentwo.org header.s=default header.b=RnYf2xIj; spf=pass (imf02.hostedemail.com: domain of cl@gentwo.org designates 62.72.0.81 as permitted sender) smtp.mailfrom=cl@gentwo.org; dmarc=pass (policy=reject) header.from=gentwo.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1726658084; a=rsa-sha256; cv=none; b=RFFY2qnCMXi9nFe7zTLFEpjbVuStUx5Or5SY19EOH/Hd1pnVAV233InSBxqwNWboctGhg3 aCXb0fr9ngZJGHxJIedMaFp+yQaHNyey9zFPZWydieOtzULnr3KDC7rqVKrJaAfjsp33iH mDlAT9YAcahLSypT6W5sTs/6QBuehzI= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gentwo.org; s=default; t=1726657424; bh=ZgUWGooFw76r+k5wBvmlHDduQIe0avoz9de+sDKki94=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=RnYf2xIjia8kxFaxgE5zNbG1A4jQohfdQhO9/HqyD7NHlSSZ+uqty1MGTQhdUUSnB 4+e7y0HXJ78In+FNkWr+1jUsmr10WlgqINk7f04CDnG+iUb19ZniyUC2k15r+u4xoO //LIPfjTRRkUHc71bLql/EdvKlGy+hUvgvnJAXII= Received: by gentwo.org (Postfix, from userid 1003) id 7D55D401CA; Wed, 18 Sep 2024 04:03:44 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by gentwo.org (Postfix) with ESMTP id 7C90A401C5; Wed, 18 Sep 2024 04:03:44 -0700 (PDT) Date: Wed, 18 Sep 2024 04:03:44 -0700 (PDT) From: "Christoph Lameter (Ampere)" To: Will Deacon 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 In-Reply-To: <20240917071246.GA27290@willie-the-truck> Message-ID: <4b546151-d5e1-22a3-a6d5-167a82c5724d@gentwo.org> References: <20240912-seq_optimize-v3-1-8ee25e04dffa@gentwo.org> <20240917071246.GA27290@willie-the-truck> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Rspamd-Server: rspam03 X-Rspam-User: X-Rspamd-Queue-Id: C44A280007 X-Stat-Signature: hgxrgghmr9ob1qgjc8c3zzgwcbsse7ko X-HE-Tag: 1726658140-698280 X-HE-Meta: U2FsdGVkX1+JBxWqVrLHFB6pcG94Miyd0yhpRwgiMpAqOwg/LhQv6LeUq57J7ovfRLM5ncGKchrzZi29sL4Q5AaNML8gTJ4RnNta+vPkqXoMUvc5nlzA3WA6AqKIZvMF2gsw6sf6eTusMMvuFWX5CPRa319BEtP9KeiI+0mvWDC/acZ/ITrbgDV+YAgV1doa526SZA9t1RdMdckpdBivXnz7BjX9JUjOxXgqS5QmoQzIRYFT7lN9bUpuDMcSKI+i/87aQ+C74piAmehS7zPDrdrOCq3b8cYDH/I3OUZnE8jQfpTwXi0WxmY2Rr2OTUJAtCNVK4wXnESEt0C/Ql2MYeFqMzRxpNDf3J36E/6XmnHQ7VbWIh23Ppgc1IiJl5OmcusVxcT1Se1F3CwJAMk/zqTZSPVX1N8oVwPaQaFTZvj3zVOfuqaHMz3BBhqiHtsnUunv0WGf+zY91/4+4qwKnNXDyXy3XUaRUb491CjcQGus/6QQYtY0RI8WaC/Cfwsk5LRZRovwXwbmvXj4HGhoRSzRCsk25ExfMC+eKaMgud3sa90IHJbLCt4hKEKtm6/o4UeB1jc9sn6tQZNB9EjcEtoydIHyUektwhomKlhDlQv+9vabI2VrM4HA9K0ZKsbo/tF82oll/MeUChTEa44rtssmU+9yjO80eikr177YVT1B4tnXZqaFykKuY1yom2XWmVJWvg2lm+CdecEvnyV9vYbScQhNFtFW0CN33PvtABvdp1FIrKESTvFCS3Xbpbqm0owPZ3/lIpc7LAzlpPC/MOto894+0NKLm9z02aJzORRKPLTRIxmEXEtPb4Sqq6QzxWQEVaICG2JHjAJ73M/SWe4nLNPUrqkrlQ+7O/llPel42yl9+3T/P2Shcve+ZHFhmwiRHnEBOQMfe6jJ/JkzzXNwwyv7ozLM+d1UakL2h/zZbq81BTh0h3W1qDT6SA7tuFLdzgS02swBXYVRpHB Syjhdv49 TuxUlSyvYJj1+9BGQgftcTcsDJIyUwEj+CECFdLZN9J5A+rI2jPuxKyhhWTzds7j69hEP44SvtOv9df7TnJqhe2SSLhYUSfC4EEmekupmH2P/ThGtIPYrCsaa6l/EbIHTDiklCbq5yMtTyLLL9KBEC+6ILtcUTfvlc4AsmkxT4B31Q8rixqwqbC2l6w4eHnSO6Ts2ie2S7uD7sE/xlZ85WlF6jvTYe3CiP/yX8bt8V5Tl7/0tb9wAgM6WvPqy/FhhCP5GpbiJVt6b0Zrux/JaqwOtqofc3GdqSCEwm8gdKLEg/fFuwu29+Arp6+o8EmoKgHS9 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 Tue, 17 Sep 2024, Will Deacon wrote: > > +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? 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. > > + 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. Hmmm... The compiler seems to have optimized that out. Will use VAL in next rollup.