From: tip-bot for Ingo Molnar <tipbot@zytor.com>
To: linux-tip-commits@vger.kernel.org
Cc: linux-kernel@vger.kernel.org, hpa@zytor.com, mingo@kernel.org,
torvalds@linux-foundation.org, a.p.zijlstra@chello.nl,
paulmck@linux.vnet.ibm.com, akpm@linux-foundation.org,
tglx@linutronix.de
Subject: [tip:core/locking] Documentation/memory-barriers.txt: Fix a typo in the data dependency description
Date: Fri, 22 Nov 2013 04:31:17 -0800 [thread overview]
Message-ID: <tip-e0edc78f25c020dea66742c05a7fbcb2ff3df629@git.kernel.org> (raw)
Commit-ID: e0edc78f25c020dea66742c05a7fbcb2ff3df629
Gitweb: http://git.kernel.org/tip/e0edc78f25c020dea66742c05a7fbcb2ff3df629
Author: Ingo Molnar <mingo@kernel.org>
AuthorDate: Fri, 22 Nov 2013 11:24:53 +0100
Committer: Ingo Molnar <mingo@kernel.org>
CommitDate: Fri, 22 Nov 2013 11:46:12 +0100
Documentation/memory-barriers.txt: Fix a typo in the data dependency description
This typo has been there forever, it is 7.5 years old, looks like this
section of our memory ordering documentation is a place where most eyes
are glazed over already ;-)
[ Also fix some stray spaces and stray tabs while at it, shrinking the
file by 49 bytes. Visual output unchanged. ]
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Link: http://lkml.kernel.org/n/tip-gncea9cb8igosblizfqMXrie@git.kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
---
Documentation/memory-barriers.txt | 42 +++++++++++++++++++--------------------
1 file changed, 21 insertions(+), 21 deletions(-)
diff --git a/Documentation/memory-barriers.txt b/Documentation/memory-barriers.txt
index c8c42e6..020cccd 100644
--- a/Documentation/memory-barriers.txt
+++ b/Documentation/memory-barriers.txt
@@ -500,7 +500,7 @@ odd-numbered bank is idle, one can see the new value of the pointer P (&B),
but the old value of the variable B (2).
-Another example of where data dependency barriers might by required is where a
+Another example of where data dependency barriers might be required is where a
number is read from memory and then used to calculate the index for an array
access:
@@ -882,12 +882,12 @@ cache it for later use.
Consider:
- CPU 1 CPU 2
+ CPU 1 CPU 2
======================= =======================
- LOAD B
- DIVIDE } Divide instructions generally
- DIVIDE } take a long time to perform
- LOAD A
+ LOAD B
+ DIVIDE } Divide instructions generally
+ DIVIDE } take a long time to perform
+ LOAD A
Which might appear as this:
@@ -910,13 +910,13 @@ Which might appear as this:
Placing a read barrier or a data dependency barrier just before the second
load:
- CPU 1 CPU 2
+ CPU 1 CPU 2
======================= =======================
- LOAD B
- DIVIDE
- DIVIDE
+ LOAD B
+ DIVIDE
+ DIVIDE
<read barrier>
- LOAD A
+ LOAD A
will force any value speculatively obtained to be reconsidered to an extent
dependent on the type of barrier used. If there was no change made to the
@@ -1887,8 +1887,8 @@ functions:
space should suffice for PCI.
[*] NOTE! attempting to load from the same location as was written to may
- cause a malfunction - consider the 16550 Rx/Tx serial registers for
- example.
+ cause a malfunction - consider the 16550 Rx/Tx serial registers for
+ example.
Used with prefetchable I/O memory, an mmiowb() barrier may be required to
force stores to be ordered.
@@ -1955,19 +1955,19 @@ barriers for the most part act at the interface between the CPU and its cache
:
+--------+ +--------+ : +--------+ +-----------+
| | | | : | | | | +--------+
- | CPU | | Memory | : | CPU | | | | |
- | Core |--->| Access |----->| Cache |<-->| | | |
+ | CPU | | Memory | : | CPU | | | | |
+ | Core |--->| Access |----->| Cache |<-->| | | |
| | | Queue | : | | | |--->| Memory |
- | | | | : | | | | | |
- +--------+ +--------+ : +--------+ | | | |
+ | | | | : | | | | | |
+ +--------+ +--------+ : +--------+ | | | |
: | Cache | +--------+
: | Coherency |
: | Mechanism | +--------+
+--------+ +--------+ : +--------+ | | | |
| | | | : | | | | | |
| CPU | | Memory | : | CPU | | |--->| Device |
- | Core |--->| Access |----->| Cache |<-->| | | |
- | | | Queue | : | | | | | |
+ | Core |--->| Access |----->| Cache |<-->| | | |
+ | | | Queue | : | | | | | |
| | | | : | | | | +--------+
+--------+ +--------+ : +--------+ +-----------+
:
@@ -2090,7 +2090,7 @@ CPU's caches by some other cache event:
p = &v; q = p;
<D:request p>
<B:modify p=&v> <D:commit p=&v>
- <D:read p>
+ <D:read p>
x = *q;
<C:read *q> Reads from v before v updated in cache
<C:unbusy>
@@ -2115,7 +2115,7 @@ queue before processing any further requests:
p = &v; q = p;
<D:request p>
<B:modify p=&v> <D:commit p=&v>
- <D:read p>
+ <D:read p>
smp_read_barrier_depends()
<C:unbusy>
<C:commit v=2>
next reply other threads:[~2013-11-22 12:31 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-11-22 12:31 tip-bot for Ingo Molnar [this message]
2013-11-22 13:57 ` [tip:core/locking] Documentation/memory-barriers.txt: Fix a typo in the data dependency description 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=tip-e0edc78f25c020dea66742c05a7fbcb2ff3df629@git.kernel.org \
--to=tipbot@zytor.com \
--cc=a.p.zijlstra@chello.nl \
--cc=akpm@linux-foundation.org \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-tip-commits@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=paulmck@linux.vnet.ibm.com \
--cc=tglx@linutronix.de \
--cc=torvalds@linux-foundation.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