From: Akira Yokosawa <akiyks@gmail.com>
To: Ignacio Encinas Rubio <ignacio@iencinas.com>
Cc: perfbook@vger.kernel.org, "Paul E. McKenney" <paulmck@kernel.org>,
Akira Yokosawa <akiyks@gmail.com>
Subject: Re: Is Alpha non-other-multicopy atomic?
Date: Mon, 17 Mar 2025 18:58:26 +0900 [thread overview]
Message-ID: <c1832cf9-49e6-461f-bf6c-92b6b5e7f220@gmail.com> (raw)
In-Reply-To: <03f234c4-faac-49ef-8956-2bf04579eab7@iencinas.com>
Ignacio Encinas Rubio wrote:
> On 16/3/25 12:37, Akira Yokosawa wrote:
>> As is well known, Alpha is infamous of its lack of address-dependency
>> guarantees. I don't see much point in discussing whether it is multicopy
>> atomic or not.
>
> I agree this is not particularly important, I just found contradicting
> information and wanted to clarify/fix Table 15.5.
>
>> If you have access to an Alpha machine with 3 or more CPUs,
>> you should be able to run this test with the help of klitmus7.
>
> Thanks for the test. Sadly, I don't have access to an Alpha CPU (I was
> born after DEC was bought by Compaq)
That is what I had anticipated ...
>
>> Finally, my mental model of other-multi-copy might be different from
>> those defined in papers you cited below.
>
> Might be, I have just realized mine is wrong. I have just run Listing
> 15.16 (C-WRC...) in herd using the "linux" model to realize the exists
> clause can trigger.
>
> Note that it can do so while "RFE" imposes order for the "linux" model
> (it is part of happens-before), so my original comment stating
>
> non-mca == rfe does not impose order
>
> is wrong if Read[X = 0] (fr) -> Write[X = 1] does not mean that the read
> is ordered before the write. However, this doesn't seem to be the case
> for Alpha [3]
>
> Section 5.6.1.2: The ordering relation Before (<=) is acyclic
> Section 5.6.1.4: If u and v are overlapping read/write accesses, at
> least one of which is a write, then u and v must be comparable in
> the BEFORE (<=) ordering, that is, either u <= v or v <= u.
>
The wording "If u and v are overlapping read/write accesses" sounds to
me like it has nothing to do with what perfbook calls "multicopy atomicity".
It is more related to the concept of perfbook's "single-copy atomicity" or
"coherency", isn't it?
Quite from Section 15.3.6:
On cache-coherent platforms, all CPUs agree on the order of loads and
stores to a given variable. Fortunately, when READ_ONCE() and WRITE_ONCE()
are used, almost all platforms are cache-coherent, as indicated by the "SV"
column of the cheat sheet shown in Table 15.3. Unfortunately, this property
is so popular that it has been named multiple times, with "single-variable
SC", "single-copy atomic" [SF95], and just plain "coherence" [AMP+11]
having seen use.
Miss-orderings related to address-dependent loads on Alpha happen only
when two variables belong to two different cache banks as shown in
Figure 15.25.
They don't happen when u and v overlap (and share a cache line).
I'm suspecting that the meaning of "multicopy atomicity" in perfbook
(or LKMM), and/or my interpretation of it, might not be exactly the
same as what is widely accepted by computer industry people.
Are we on the same page now?
> It's still my opinion that Alpha is other-multi-copy atomic but I
> understand it is a bit pointless to discuss about this... Sorry, I
> couldn't resist.
No need to apologize.
Any feedback from a fresh minded reader is much appreciated!
Thanks, Akira
>
> Thanks
>
> [3] https://download.majix.org/dec/alpha_arch_ref.pdf
>
>
next prev parent reply other threads:[~2025-03-17 9:58 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-02-28 17:31 Is Alpha non-other-multicopy atomic? Ignacio Encinas Rubio
2025-02-28 17:34 ` Ignacio Encinas Rubio
2025-03-16 11:37 ` Akira Yokosawa
2025-03-16 17:12 ` Ignacio Encinas Rubio
2025-03-17 9:58 ` Akira Yokosawa [this message]
2025-03-18 18:16 ` Ignacio Encinas Rubio
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=c1832cf9-49e6-461f-bf6c-92b6b5e7f220@gmail.com \
--to=akiyks@gmail.com \
--cc=ignacio@iencinas.com \
--cc=paulmck@kernel.org \
--cc=perfbook@vger.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.