The preceding paragraph discusses update performance regarding
Figure 10.12.
This paragraph returns to Figure 10.11 and speculates that the rate
of lookup might be affected by the differences of update rates.
To help readers to follow the discussion flow, add a reference to
Figure 10.11 near the beginning of the paragraph.
Also fix a typo in the reworked answer to QQ 10.9.
Signed-off-by: Akira Yokosawa <akiyks@xxxxxxxxx>
---
datastruct/datastruct.tex | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/datastruct/datastruct.tex b/datastruct/datastruct.tex
index 552bd955..d703a741 100644
--- a/datastruct/datastruct.tex
+++ b/datastruct/datastruct.tex
@@ -940,7 +940,8 @@ starts to make its presence known, first for RCU and then for hazard
pointers.
Of course, all three of these implementations beat global locking.
-It is quite possible that the differences in lookup performance
+It is quite possible that the differences in lookup performance observed in
+\cref{fig:datastruct:Read-Side RCU-Protected Hash-Table Performance For Schroedinger's Zoo in the Presence of Updates}
are affected by the differences in update rates.
One way to check this is to artificially throttle the update rates of
per-bucket locking and hazard pointers to match that of RCU\@.
@@ -969,7 +970,7 @@ not recommended for production use.
In addition, other testing has shown that RCU read-side primitives
offer consistent performance and scalability up to at least 1024~CPUs.
- However, is useful to review
+ However, it is useful to review
\cref{fig:datastruct:Read-Only RCU-Protected Hash-Table Performance For Schr\"odinger's Zoo at 448 CPUs; Varying Table Size}
and its associated commentary.
You see, unlike the 448-CPU system that provided this data,
--
2.17.1
