From: "Christoph Lameter (Ampere)" <cl@gentwo.org>
To: Waiman Long <longman@redhat.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will@kernel.org>,
Peter Zijlstra <peterz@infradead.org>,
Ingo Molnar <mingo@redhat.com>,
Boqun Feng <boqun.feng@gmail.com>,
Linus Torvalds <torvalds@linux-foundation.org>,
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
Date: Tue, 13 Aug 2024 12:41:11 -0700 (PDT) [thread overview]
Message-ID: <147572ea-c5ae-7992-6015-3181f10a785e@gentwo.org> (raw)
In-Reply-To: <183ee6fa-1d42-4a01-8446-4f20942680d2@redhat.com>
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.
next prev parent reply other threads:[~2024-08-13 19:48 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-08-13 18:26 Christoph Lameter via B4 Relay
2024-08-13 19:01 ` Waiman Long
2024-08-13 19:41 ` Christoph Lameter (Ampere) [this message]
2024-08-13 19:48 ` Linus Torvalds
2024-08-13 19:58 ` Waiman Long
2024-08-13 20:01 ` Linus Torvalds
2024-08-13 20:23 ` Waiman Long
2024-08-19 8:45 ` Mark Rutland
2024-08-19 16:25 ` Linus Torvalds
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=147572ea-c5ae-7992-6015-3181f10a785e@gentwo.org \
--to=cl@gentwo.org \
--cc=boqun.feng@gmail.com \
--cc=catalin.marinas@arm.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=longman@redhat.com \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=torvalds@linux-foundation.org \
--cc=will@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox