All of lore.kernel.org
 help / color / mirror / Atom feed
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
> 
>


  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.