1 files changed, 14 insertions, 11 deletions
diff --git a/Documentation/RCU/RTFP.txt b/Documentation/RCU/RTFP.txt
index fcbcbc35b122..6221464d1a7e 100644
--- a/Documentation/RCU/RTFP.txt
+++ b/Documentation/RCU/RTFP.txt
@@ -90,16 +90,20 @@ at OLS.  The resulting abundance of RCU patches was presented the
 following year [McKenney02a], and use of RCU in dcache was first
 described that same year [Linder02a].
-Also in 2002, Michael [Michael02b,Michael02a] presented techniques
+Also in 2002, Michael [Michael02b,Michael02a] presented "hazard-pointer"
-that defer the destruction of data structures to simplify non-blocking
+techniques that defer the destruction of data structures to simplify
-synchronization (wait-free synchronization, lock-free synchronization,
+non-blocking synchronization (wait-free synchronization, lock-free
-and obstruction-free synchronization are all examples of non-blocking
+synchronization, and obstruction-free synchronization are all examples of
-synchronization).  In particular, this technique eliminates locking,
+non-blocking synchronization).  In particular, this technique eliminates
-reduces contention, reduces memory latency for readers, and parallelizes
+locking, reduces contention, reduces memory latency for readers, and
-pipeline stalls and memory latency for writers.  However, these
+parallelizes pipeline stalls and memory latency for writers.  However,
-techniques still impose significant read-side overhead in the form of
+these techniques still impose significant read-side overhead in the
-memory barriers.  Researchers at Sun worked along similar lines in the
+form of memory barriers.  Researchers at Sun worked along similar lines
-same timeframe [HerlihyLM02,HerlihyLMS03].
+in the same timeframe [HerlihyLM02,HerlihyLMS03].  These techniques
+can be thought of as inside-out reference counts, where the count is
+represented by the number of hazard pointers referencing a given data
+structure (rather than the more conventional counter field within the
+data structure itself).
 In 2003, the K42 group described how RCU could be used to create
 hot-pluggable implementations of operating-system functions.  Later that
@@ -113,7 +117,6 @@ number of operating-system kernels [PaulEdwardMcKenneyPhD], a paper
 describing how to make RCU safe for soft-realtime applications [Sarma04c],
 and a paper describing SELinux performance with RCU [JamesMorris04b].
 2005 has seen further adaptation of RCU to realtime use, permitting
 preemption of RCU realtime critical sections [PaulMcKenney05a,
 PaulMcKenney05b].

diff --git a/Documentation/RCU/RTFP.txt b/Documentation/RCU/RTFP.txt index fcbcbc35b122..6221464d1a7e 100644 --- a/Documentation/RCU/RTFP.txt +++ b/Documentation/RCU/RTFP.txt
@@ -90,16 +90,20 @@ at OLS. The resulting abundance of RCU patches was presented the
90	following year [McKenney02a], and use of RCU in dcache was first	90	following year [McKenney02a], and use of RCU in dcache was first
91	described that same year [Linder02a].	91	described that same year [Linder02a].
92		92
93	Also in 2002, Michael [Michael02b,Michael02a] presented techniques	93	Also in 2002, Michael [Michael02b,Michael02a] presented "hazard-pointer"
94	that defer the destruction of data structures to simplify non-blocking	94	techniques that defer the destruction of data structures to simplify
95	synchronization (wait-free synchronization, lock-free synchronization,	95	non-blocking synchronization (wait-free synchronization, lock-free
96	and obstruction-free synchronization are all examples of non-blocking	96	synchronization, and obstruction-free synchronization are all examples of
97	synchronization). In particular, this technique eliminates locking,	97	non-blocking synchronization). In particular, this technique eliminates
98	reduces contention, reduces memory latency for readers, and parallelizes	98	locking, reduces contention, reduces memory latency for readers, and
99	pipeline stalls and memory latency for writers. However, these	99	parallelizes pipeline stalls and memory latency for writers. However,
100	techniques still impose significant read-side overhead in the form of	100	these techniques still impose significant read-side overhead in the
101	memory barriers. Researchers at Sun worked along similar lines in the	101	form of memory barriers. Researchers at Sun worked along similar lines
102	same timeframe [HerlihyLM02,HerlihyLMS03].	102	in the same timeframe [HerlihyLM02,HerlihyLMS03]. These techniques
		103	can be thought of as inside-out reference counts, where the count is
		104	represented by the number of hazard pointers referencing a given data
		105	structure (rather than the more conventional counter field within the
		106	data structure itself).
103		107
104	In 2003, the K42 group described how RCU could be used to create	108	In 2003, the K42 group described how RCU could be used to create
105	hot-pluggable implementations of operating-system functions. Later that	109	hot-pluggable implementations of operating-system functions. Later that
@@ -113,7 +117,6 @@ number of operating-system kernels [PaulEdwardMcKenneyPhD], a paper
113	describing how to make RCU safe for soft-realtime applications [Sarma04c],	117	describing how to make RCU safe for soft-realtime applications [Sarma04c],
114	and a paper describing SELinux performance with RCU [JamesMorris04b].	118	and a paper describing SELinux performance with RCU [JamesMorris04b].
115		119
116
117	2005 has seen further adaptation of RCU to realtime use, permitting	120	2005 has seen further adaptation of RCU to realtime use, permitting
118	preemption of RCU realtime critical sections [PaulMcKenney05a,	121	preemption of RCU realtime critical sections [PaulMcKenney05a,
119	PaulMcKenney05b].	122	PaulMcKenney05b].