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 E7C6CC52D7B for ; Tue, 13 Aug 2024 19:48:55 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 540356B0085; Tue, 13 Aug 2024 15:48:55 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 4C97F6B0088; Tue, 13 Aug 2024 15:48:55 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 36A286B0089; Tue, 13 Aug 2024 15:48:55 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 0EBBD6B0085 for ; Tue, 13 Aug 2024 15:48:55 -0400 (EDT) Received: from smtpin10.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id B7A291A0A4C for ; Tue, 13 Aug 2024 19:48:54 +0000 (UTC) X-FDA: 82448260188.10.A8F66D6 Received: from gentwo.org (gentwo.org [62.72.0.81]) by imf11.hostedemail.com (Postfix) with ESMTP id 16FFA40023 for ; Tue, 13 Aug 2024 19:48:52 +0000 (UTC) Authentication-Results: imf11.hostedemail.com; dkim=pass header.d=gentwo.org header.s=default header.b=BBZbZ+Sz; dmarc=pass (policy=reject) header.from=gentwo.org; spf=pass (imf11.hostedemail.com: domain of cl@gentwo.org designates 62.72.0.81 as permitted sender) smtp.mailfrom=cl@gentwo.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1723578480; a=rsa-sha256; cv=none; b=MIFbmIzshM8Lxoir4lb9TycOwPvsXTb3WsohRtdO6W6VCX2N41V0WOTuA5NORw0h0mmmFd SiXHsQPjn6E+qmXEvxG1JUpAtM5uLrfUxOlVZ6Ggtd2/35CNN3z2wZ727veNH//D7q8yXc qQc/b/5LYckJ/X8o5o4H9KMD92i52eo= ARC-Authentication-Results: i=1; imf11.hostedemail.com; dkim=pass header.d=gentwo.org header.s=default header.b=BBZbZ+Sz; dmarc=pass (policy=reject) header.from=gentwo.org; spf=pass (imf11.hostedemail.com: domain of cl@gentwo.org designates 62.72.0.81 as permitted sender) smtp.mailfrom=cl@gentwo.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1723578480; 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=ea3yNX25t1HlOj5Tx99qiVPGH8h4hKqQJcVcDcbd3i0=; b=qYlXcvJJccLLX34Xzt6lJQV+MBwf6mbjSbqDr80kwrep8gWynvNcLpspuCnlrfijcxxJKA wAGcjoQX/+LjVDTQS2dD0VbR34Ww9Ikr1xE4SD3RZwt20M/1QGE0ECWCc1DCMnaLnQJG89 nJR2Z+LRGO4GaqzNxZqj5RMkH8vjyts= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gentwo.org; s=default; t=1723578071; bh=ujAzKhvz2m85q9OKAVeMysx4OHTHQ3MJssBelvEs0NY=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=BBZbZ+SztijdgLY0TVQ4M0iRQlHQ6u/Nwv47FTIhHi+NOoipKuvuKsatk71urBcSe wlzbeGoJLodwSmPqxRRmsq4vA/S9cf/zhRHMIQer3+HAuxE2We2FnUXCGm9zll7Cwb rcw5wy29kaG9Va/LST1S0Ckm4qguoFdl2EQWk0e0= Received: by gentwo.org (Postfix, from userid 1003) id 5B852400CA; Tue, 13 Aug 2024 12:41:11 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by gentwo.org (Postfix) with ESMTP id 5A5CD400C5; Tue, 13 Aug 2024 12:41:11 -0700 (PDT) Date: Tue, 13 Aug 2024 12:41:11 -0700 (PDT) From: "Christoph Lameter (Ampere)" To: Waiman Long cc: Catalin Marinas , Will Deacon , Peter Zijlstra , Ingo Molnar , Boqun Feng , Linus Torvalds , linux-mm@kvack.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org Subject: Re: [PATCH RFC] Avoid memory barrier in read_seqcount() through load acquire In-Reply-To: <183ee6fa-1d42-4a01-8446-4f20942680d2@redhat.com> Message-ID: <147572ea-c5ae-7992-6015-3181f10a785e@gentwo.org> References: <20240813-seq_optimize-v1-1-84d57182e6a7@gentwo.org> <183ee6fa-1d42-4a01-8446-4f20942680d2@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed X-Rspamd-Queue-Id: 16FFA40023 X-Rspam-User: X-Rspamd-Server: rspam05 X-Stat-Signature: yzkdpo1dofgx646x4deogjjws1qb9ctg X-HE-Tag: 1723578532-218518 X-HE-Meta: U2FsdGVkX1+IKU2npQ5SlLW8srtuH1heuCpNhcDG9fWWdymiBxgcQkCLwQpot9olXWpAGdV4Pq0gA9A9o3KGidXBr+qlFiIHYvwe+fa+F8H0Z0Js3la/ZcZvnFxwksAJKI6e1U1TilOse5NZdcxokm4CH+SVXD5h6Nx2H9sHbvqxKeqCUpDz42vYZOPp3lHoKnCSr6tS8gzNnDhLJ+bu/KKgDAer216zkec+Q3khq2UsMxbYanvFHp5aqQ6pXhNyGTj/FspDMNXu3JZGrDqpZ6RxKoUkO1BR4dkqJ3vKZfPvOkhZgLwhucELZpafprK/R0+qoyer5ljcswQV7QM174oSibpynGpD0od0ZMGxJiMXpvyYveqX+pkQrF4tS4GFhSmbFUqful9abGk9zPvGCSj/pWzreZDsnx5R7FL5radt6DvuBoeXvNpbDfUKQRWd7suJGw8wnpSwlfQyLjBX8p/XhaagkwJaQYBRyni1M/OA+lrsPx0wn2wjFXamEbmxHMXopJVF81+s6q5XIfvwy35IHjsff1TFnCA1KBmopgoYYo0M2rHbaSC9a4IIXAe0XRQeVEZOccyu3pBhPVrrr2A6/5w1t09RAKsb4CnaAlRpCyYj6ZW8iBWEny3Kq0UiDliymMvcWl4tSUOMp2xy5ZeNUWm2Ij3P4x6fCG2QS6s3VjoQbWi83hhmGPmtj13MbwL+EFAM96tVE6jcbNVLnx6T0R2ahSzBfrIRWhP6XAzALXYGtIuI7//43gbeouDz7NU0x4h7CFBwk6ybJ6f+P0aE0duCpbX11KV6/+qAd839GgETifi7kU6U7/7tSQZtiDACFl59DUUjmoaGDVlQsCqTKJzyDW8eb6U5yLKq2wTE7h0USMDGXBRZwoViEqwh63aC8ZJLH0MfihbZpE/mCE5cJf+hNdNcENrvlL1jsyGG1pWFTFjQ1WlNEpIes3TWrYiYFRTmQcz3MbR6ESp 81WhHVMR 9cIr2x0i1C/ppMFThihShcXilSIsvO1EOoWjHqvpgSqQKrMG4Z6y0ubcMxOTYuvPqkFf0kZyjSYuluWI/qY3z8oM7MBbGYTHoCOoptqEnIPj7x4TNbKohh+7y7RJx1LwV9wAeWNrA5avRo051eeayMpCBOn/CSJu3R8haoqRh0FnhkRV4URL9A899cA1dt4wRr7nkGVhaz2YNh8WEbMwCpwgWxaRPCE08R8BfeOp9/dcxZ8pnqatUVvS2LwvYDVpM4sKtTo+YzBjzyO3CwD8nEOkq3JaidPkN4GjVyBqU++2NdFc= 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, 13 Aug 2024, Waiman Long wrote: > Do we need a new ARCH flag? I believe barrier APIs like smp_load_acquire() > will use the full barrier for those arch'es that don't define their own > smp_load_acquire(). Well this is a load acquire instruction. The fallback of smp_load_aquire is: #define __smp_load_acquire(p) \ ({ \ __unqual_scalar_typeof(*p) ___p1 = READ_ONCE(*p); \ compiletime_assert_atomic_type(*p); \ __smp_mb(); \ (typeof(*p))___p1; \ }) Looks like we have an acquire + barrier here. > BTW, acquire/release can be considered memory barriers too. Maybe you are > talking about preferring acquire/release barriers over read/write barriers. > Right? Load acquire is a single instruction load that does not require full barrier semantics for the critical section but ensures that the value is loaded before all following. Regular barriers do not have this singe load that isolates the critical section and sequence all loads around them.