>From ff1d191e40f23f5a0200ee3bbabe2073a6c03394 Mon Sep 17 00:00:00 2001
From: Akira Yokosawa <akiyks@xxxxxxxxx>
Date: Sun, 31 May 2020 08:12:02 +0900
Subject: [PATCH 1/3] defer: Annotate consecutive QQZs as such for 'nq' build
Signed-off-by: Akira Yokosawa <akiyks@xxxxxxxxx>
---
defer/rcuusage.tex | 20 +++++++++++---------
1 file changed, 11 insertions(+), 9 deletions(-)
diff --git a/defer/rcuusage.tex b/defer/rcuusage.tex
index d5329a39..72c1f331 100644
--- a/defer/rcuusage.tex
+++ b/defer/rcuusage.tex
@@ -241,12 +241,13 @@ reader-writer locking are shown in
Figure~\ref{fig:defer:Performance Advantage of RCU Over Reader-Writer Locking},
which was generated on a 448-CPU 2.10\,GHz Intel x86 system.
-\QuickQuiz{
+\QuickQuizSeries{%
+\QuickQuizB{
WTF?
How the heck do you expect me to believe that RCU can have less
than a 300-picosecond overhead when the clock period at 2.10\,GHz
is almost 500\,picoseconds?
-}\QuickQuizAnswer{
+}\QuickQuizAnswerB{
First, consider that the inner loop used to
take this measurement is as follows:
@@ -290,13 +291,13 @@ which was generated on a 448-CPU 2.10\,GHz Intel x86 system.
It certainly is not just every day that a timing measurement
of 267 picoseconds turns out to be an overestimate!
-}\QuickQuizEnd
+}\QuickQuizEndB
-\QuickQuiz{
+\QuickQuizM{
Didn't an earlier release of this book show RCU read-side
overhead way down in the sub-picosecond range?
What happened???
-}\QuickQuizAnswer{
+}\QuickQuizAnswerM{
Excellent memory!!!
The overhead in some early releases was in fact roughly
100~femtoseconds.
@@ -328,12 +329,12 @@ which was generated on a 448-CPU 2.10\,GHz Intel x86 system.
So which change had the most effect, Linus's commit or the change in
the system?
This question is left as an exercise to the reader.
-}\QuickQuizEnd
+}\QuickQuizEndM
-\QuickQuiz{
+\QuickQuizE{
Why is there such large variation for the \co{rcu} trace in
Figure~\ref{fig:defer:Performance Advantage of RCU Over Reader-Writer Locking}?
-}\QuickQuizAnswer{
+}\QuickQuizAnswerE{
Keep in mind that this is a log-log plot, so those large-seeming
\co{rcu} variances in reality span only a few hundred picoseconds.
And that is such a short time that anything could cause it.
@@ -347,7 +348,8 @@ which was generated on a 448-CPU 2.10\,GHz Intel x86 system.
Attempting to reduce these variations by running the guest OSes
at real-time priority (as suggested by Joel Fernandes) is left
as an exercise for the reader.
-}\QuickQuizEnd
+}\QuickQuizEndE
+} % End of \QuickQuizSeries
Note that reader-writer locking is more than an order of magnitude slower
than RCU on a single CPU, and is more than \emph{four} orders of magnitude
--
2.17.1
