All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
To: Akira Yokosawa <akiyks@gmail.com>
Cc: perfbook@vger.kernel.org
Subject: Re: Other-multicopy atomicity
Date: Sat, 2 Sep 2017 17:57:44 -0700	[thread overview]
Message-ID: <20170903005744.GK19872@linux.vnet.ibm.com> (raw)
In-Reply-To: <a5f7959b-cfe3-9bc3-3f65-7b1f9577ad99@gmail.com>

On Sat, Sep 02, 2017 at 01:09:37PM +0900, Akira Yokosawa wrote:
> Hi Paul,
> 
> I have a comment on the term "other-multicompy atomicity".
> 
> It took a while for me to realize that the "other-" stands for "other than self CPU".
> At first, it sounded like "other type of multicompy atomicity", which looked
> quite vague.
> 
> Commit 43236beadb1 ("memorder: Expand on cumulativity and {other,} multicopy
> atomicity") helped me to realize your intention. May I suggest to add a footnote
> on the use of "other-"?

I am trying to do a bit too much with that paragraph, aren't I?

How about the patch below?

> Also, you failed to replace tabs to white spaces in listing added in the
> above mentioned commit.

Good eyes, fixed!  (Not yet pushed, will get there.)

							Thanx, Paul

------------------------------------------------------------------------

commit 87b29716cee78c5505039ba933c2f991ed3b1dec
Author: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Date:   Sat Sep 2 17:48:39 2017 -0700

    memorder: Clarify other-multicopy atomicity
    
    Reported-by: Akira Yokosawa <akiyks@gmail.com>
    Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>

diff --git a/memorder/memorder.tex b/memorder/memorder.tex
index 62544ae8ed52..90e2b5e2f294 100644
--- a/memorder/memorder.tex
+++ b/memorder/memorder.tex
@@ -1703,32 +1703,32 @@ and other counterintuitive behavior, as discussed in the next section.
 
 Threads running on a \emph{multicopy atomic}~\cite{Stone:1995:SP:623262.623912}
 platform are guaranteed
-to agree on the order of writes, even to different variables.
+to agree on the order of stores, even to different variables.
 A useful mental model of such a system is the single-bus architecture
 shown in
 Figure~\ref{fig:memorder:Global System Bus And Multi-Copy Atomicity}.
-If each write resulted in a message on the bus, and if the bus could
-accommodate only one write at a time, then any pair of CPUs would
-agree on the order of all writes that they observed.
+If each store resulted in a message on the bus, and if the bus could
+accommodate only one store at a time, then any pair of CPUs would
+agree on the order of all stores that they observed.
 Unfortunately, building a computer system as shown in the figure,
 without store buffers or even caches, would result in glacial computation.
-CPU vendors have therefore taken one of three approaches:
-(1)~Provide store buffers, caches, and the rest and abandon
-multicopy atomicity (weakly ordered platforms),
-(2)~Provide all those hardware optimizations, and invest many transistors
-into preserving multicopy atomicity (TSO platforms), or
-(3)~Define a slightly weaker \emph{other-multicopy atomicity} that allows
-a given CPU's stores to become visible to that CPU before they become visible
-to other CPUs, but in which each of those stores becomes visible to all
-the other CPUs simultaneously~\cite{ARMv8A:2017}.
-Perhaps there will come a day when all platforms provide some flavor
-of multi-copy atomicity, but
-in the meantime, non-multicopy-atomic platforms do exist, and so software
-does need to deal with them.
+CPU vendors interested in providing multicopy atomicity have therefore
+instead provided the slightly weaker
+\emph{other-multicopy atomicity}~\cite{ARMv8A:2017},
+which excludes the CPU doing a given store from the requirement that all
+CPUs agree on the order of all stores.
+This means that if only a subset of CPUs are doing stores, the
+other CPUs will agree on the order of stores, hence the ``other''
+in ``other-multicopy atomicity''.
+Unlike multicopy-atomic platforms, within other-multicopy-atomic platforms,
+the CPU doing the store is permitted to observe its
+store early, which allows its later loads to obtain the newly stored
+value directly from the store buffer.
+This in turn improves performance.
 
 \QuickQuiz{}
 	Can you give a specific example showing different behavior for
-	multicopy atomic on the one hand and other multicopy atomic
+	multicopy atomic on the one hand and other-multicopy atomic
 	on the other?
 \QuickQuizAnswer{
 \begin{listing}[tbp]
@@ -1790,6 +1790,12 @@ exists (1:r1=1 /\ 1:r2=0)
 	which in turn allows the \co{exists} clause to trigger.
 } \QuickQuizEnd
 
+
+Perhaps there will come a day when all platforms provide some flavor
+of multi-copy atomicity, but
+in the meantime, non-multicopy-atomic platforms do exist, and so software
+does need to deal with them.
+
 \begin{listing}[tbp]
 { \scriptsize
 \begin{verbbox}[\LstLineNo]

--
To unsubscribe from this list: send the line "unsubscribe perfbook" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  https://urldefense.proofpoint.com/v2/url?u=http-3A__vger.kernel.org_majordomo-2Dinfo.html&d=DwIBAg&c=jf_iaSHvJObTbx-siA1ZOg&r=ux41CW3B5BSVxDMRNRWyLbUmPebZc70Kq4AkfdiRGMI&m=4C4QF7BfbGArvD2WxudLaa7Qm9wEkEiEvkE5vbtD8PE&s=jilcBkgE1e1AY60gJfhiKpDB00kxiL--FmmprNHWFw0&e= 


  reply	other threads:[~2017-09-03  0:57 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-09-02  4:09 Other-multicopy atomicity Akira Yokosawa
2017-09-03  0:57 ` Paul E. McKenney [this message]
2017-09-03  2:02   ` Akira Yokosawa
2017-09-03  3:06     ` Paul E. McKenney
2017-09-03  5:40       ` Akira Yokosawa

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=20170903005744.GK19872@linux.vnet.ibm.com \
    --to=paulmck@linux.vnet.ibm.com \
    --cc=akiyks@gmail.com \
    --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.