From: Linus Torvalds <torvalds@linux-foundation.org>
To: Mark Rutland <mark.rutland@arm.com>
Cc: cl@gentwo.org, Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will@kernel.org>,
Peter Zijlstra <peterz@infradead.org>,
Ingo Molnar <mingo@redhat.com>, Waiman Long <longman@redhat.com>,
Boqun Feng <boqun.feng@gmail.com>,
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: Mon, 19 Aug 2024 09:25:45 -0700 [thread overview]
Message-ID: <CAHk-=whTtu-7NxtsVMzxVWXaRM1rcCWYEVL8hwNxEVEqpfZETQ@mail.gmail.com> (raw)
In-Reply-To: <ZsMGRIec1y8hdKRG@J2N7QTR9R3.cambridge.arm.com>
On Mon, 19 Aug 2024 at 01:46, Mark Rutland <mark.rutland@arm.com> wrote:
>
> If you cannot disclose that for some reason, just say "on my ARM64 test
> machine" or something like that, so that we're not implying that this is
> true for all ARM64 implementations.
It's the same machine I have - an Ampere Altra. It's a standard
Neoverse N1 core, afaik.
It might also be a good idea to just point to the ARM documentation,
although I don't know how stable those web addresses are:
https://developer.arm.com/documentation/102336/0100/Load-Acquire-and-Store-Release-instructions
and quoting the relevant part on that page:
"Weaker ordering requirements that are imposed by Load-Acquire and
Store-Release instructions allow for micro-architectural
optimizations, which could reduce some of the performance impacts that
are otherwise imposed by an explicit memory barrier.
If the ordering requirement is satisfied using either a Load-Acquire
or Store-Release, then it would be preferable to use these
instructions instead of a DMB"
where that last sentence is basically ARM saying that load-acquire is
better than load+DMB and should be preferred.
Linus
prev parent reply other threads:[~2024-08-19 16:26 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)
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 [this message]
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='CAHk-=whTtu-7NxtsVMzxVWXaRM1rcCWYEVL8hwNxEVEqpfZETQ@mail.gmail.com' \
--to=torvalds@linux-foundation.org \
--cc=boqun.feng@gmail.com \
--cc=catalin.marinas@arm.com \
--cc=cl@gentwo.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=longman@redhat.com \
--cc=mark.rutland@arm.com \
--cc=mingo@redhat.com \
--cc=peterz@infradead.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