[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.DEB.2.21.2405310432190.23854@angie.orcam.me.uk>
Date: Fri, 31 May 2024 04:56:28 +0100 (BST)
From: "Maciej W. Rozycki" <macro@...am.me.uk>
To: "Paul E. McKenney" <paulmck@...nel.org>
cc: John Paul Adrian Glaubitz <glaubitz@...sik.fu-berlin.de>,
Arnd Bergmann <arnd@...nel.org>, linux-alpha@...r.kernel.org,
Arnd Bergmann <arnd@...db.de>,
Richard Henderson <richard.henderson@...aro.org>,
Ivan Kokshaysky <ink@...assic.park.msu.ru>,
Matt Turner <mattst88@...il.com>, Alexander Viro <viro@...iv.linux.org.uk>,
Marc Zyngier <maz@...nel.org>,
Linus Torvalds <torvalds@...ux-foundation.org>,
linux-kernel@...r.kernel.org, Michael Cree <mcree@...on.net.nz>,
Frank Scheiner <frank.scheiner@....de>
Subject: Re: [PATCH 00/14] alpha: cleanups for 6.10
On Wed, 29 May 2024, Paul E. McKenney wrote:
> > Mind that the read-modify-write sequence that software does for sub-word
> > write accesses with original Alpha hardware is precisely what hardware
> > would have to do anyway and support for that was deliberately omitted by
> > the architecture designers from the ISA to give it performance advantages
> > quoted in the architecture manual. The only difference here is that with
> > hardware read-modify-write operations atomicity for sub-word accesses is
> > guaranteed by the ISA, however for software read-modify-write it has to be
> > explictly coded using the usual load-locked/store-conditional sequence in
> > a loop. I don't think it's a big deal really, it should be trivial to do
> > in the relevant accessors, along with the memory barriers that are needed
> > anyway for EV56+ and possibly other ports such as the MIPS one.
>
> There shouldn't be any memory barriers required, and don't EV56+ have
> single-byte loads and stores?
I should have commented on this in my original reply.
You're the RCU expert so you know the answer. I don't. If it's OK for
successive writes to get reordered, or readers to see a stale value, then
you don't need memory barriers. Otherwise you do. Whether byte accesses
are available or not does not matter, the CPU *will* do reordering if it's
allowed to (or more specifically, it won't do anything to prevent it from
happening, especially in SMP configurations; I can't remember offhand if
there are cases with UP). Also adjacent byte writes may be merged, but I
suppose it does not matter, or does it?
NB MIPS has similar architectural arrangements (and a bunch of barriers
defined in the ISA), it's just most implementations are actually strongly
ordered, so most people can't see the effects of this. With MIPS I know
for sure there are cases of UP reordering, but they only really matter for
MMIO use cases and not regular memory.
Maciej
Powered by blists - more mailing lists