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=
next prev parent 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.