From: Akira Yokosawa <akiyks@gmail.com>
To: "Paul E. McKenney" <paulmck@kernel.org>
Cc: perfbook@vger.kernel.org, Akira Yokosawa <akiyks@gmail.com>
Subject: [PATCH -perfboof] memorder: Fix word choice (data dependencies --> address dependencies)
Date: Mon, 18 Sep 2023 10:00:18 +0900 [thread overview]
Message-ID: <3f951591-8279-eeda-65d4-42cb76a2a013@gmail.com> (raw)
There remain obsolete word choices of "data dependencies" in section
Alpha.
It is load-to-load address dependencies that other archs respect.
Signed-off-by: Akira Yokosawa <akiyks@gmail.com>
---
Hi Paul,
I caught them while attempting to add index markers to
address/data/control dependency.
Thanks, Akira
--
memorder/memorder.tex | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/memorder/memorder.tex b/memorder/memorder.tex
index 1a4edf8bbb6d..86bb8f41b5f8 100644
--- a/memorder/memorder.tex
+++ b/memorder/memorder.tex
@@ -5403,7 +5403,7 @@ One could place an \co{smp_rmb()} primitive
between the pointer fetch and dereference in order to force Alpha
to order the pointer fetch with the later dependent load.
However, this imposes unneeded overhead on systems (such as \ARM,
-Itanium, PPC, and SPARC) that respect data dependencies on the read side.
+Itanium, PPC, and SPARC) that respect address dependencies on the read side.
A \co{smp_read_barrier_depends()} primitive was therefore added to the
Linux kernel to eliminate overhead on these systems, but was removed
in v5.9 of the Linux kernel in favor of augmenting Alpha's definition
@@ -5428,7 +5428,7 @@ Upon receipt of such an IPI, a CPU would execute a memory-barrier
instruction, implementing a system-wide memory barrier similar to that
provided by the Linux kernel's \co{sys_membarrier()} system call.
Additional logic is required to avoid deadlocks.
-Of course, CPUs that respect data dependencies would define such a barrier
+Of course, CPUs that respect address dependencies would define such a barrier
to simply be \co{smp_store_release()}.
However, this approach was deemed by the Linux community
to impose excessive overhead~\cite{McKenney01f}, and to their point would
base-commit: 8224a12917dd115ead6fce0f785b19a4c7d50f18
--
2.25.1
next reply other threads:[~2023-09-18 1:00 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-09-18 1:00 Akira Yokosawa [this message]
2023-09-18 5:50 ` [PATCH -perfboof] memorder: Fix word choice (data dependencies --> address dependencies) Paul E. McKenney
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=3f951591-8279-eeda-65d4-42cb76a2a013@gmail.com \
--to=akiyks@gmail.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).