defer/rcuapi: Embed Listing E.3 in Table E.3

In 2c layout, Table E.3 goes to the next page of Listing E.3.
This is partly due to the table* environment, but as both of them
are floating, there is no sure way for them to be on the same page.

Embed the listing at the bottom of the table so that they end up
in the same page and adjust the wording in the text.

For 2c layout, using the table* environment causes the snippet to
look unnecessarily wide. Instead, shrink the table by using the
\tcresizewidth macro and use the normal table environment.

Suggested-by: Paul E. McKenney <paulmck@kernel.org>
Link: https://www.spinics.net/lists/perfbook/msg04070.html
Signed-off-by: Akira Yokosawa <akiyks@gmail.com>
Signed-off-by: Paul E. McKenney <paulmck@kernel.org>

1 files changed, 27 insertions, 31 deletions

diff --git a/defer/rcuapi.tex b/defer/rcuapi.tex
index eea72597..34791918 100644
--- a/defer/rcuapi.tex
+++ b/defer/rcuapi.tex
@@ -337,40 +337,15 @@ The \apik{rcu_barrier()} primitive does this job.
 	critical sections to complete, \co{rcu_barrier()} instead waits
 	for callbacks from prior calls to \co{call_rcu()} to be invoked.
 
-\begin{listing}
-\begin{fcvlabel}[ln:defer:synchonize-rcu vs rcu-barrier]
-\begin{VerbatimL}[commandchars=\\\@\$]
-	do_something_1();			\lnlbl@ds1$
-	rcu_read_lock();			\lnlbl@rrl$
-	do_something_2();			\lnlbl@ds2$
-	call_rcu(&p->rh, f);			\lnlbl@cr$
-	do_something_3();			\lnlbl@ds3$
-	rcu_read_unlock();			\lnlbl@rrul$
-	do_something_4();			\lnlbl@ds4$
-	// f(&p->rh) invoked			\lnlbl@cb$
-	do_something_5();			\lnlbl@ds5$
-\end{VerbatimL}
-\end{fcvlabel}
-\caption{\tco{synchronize_rcu()} vs. \tco{rcu_barrier()}}
-\label{lst:defer:synchronize-rcu vs. rcu-barrier}
-\end{listing}
-
-	This distinction is illustrated by
-	\cref{lst:defer:synchronize-rcu vs. rcu-barrier}, which
-	shows code being executed by a given CPU\@.
-	For simplicity, assume that no other CPU is executing
-	\co{rcu_read_lock()}, \co{rcu_read_unlock()}, or
-	\co{call_rcu()}.
-
-
-\begin{table*}
+\begin{table}
 \renewcommand*{\arraystretch}{1.2}
 \centering
 \small
+\tcresizewidth{
 \begin{fcvref}[ln:defer:synchonize-rcu vs rcu-barrier]
 \begin{tabular}{lll}
 \toprule
-            & \multicolumn{2}{c}{Must Wait Until (in \cref{lst:defer:synchronize-rcu vs. rcu-barrier}):} \\
+            & \multicolumn{2}{c}{Must Wait Until (in the snippet):} \\
 \cmidrule{2-3}
 \multicolumn{1}{c}{Invoked at:} & \multicolumn{1}{c}{\tco{synchronize_rcu()}}
 					& \multicolumn{1}{c}{\tco{rcu_barrier()}} \\
@@ -384,12 +359,33 @@ The \apik{rcu_barrier()} primitive does this job.
 \bottomrule
 \end{tabular}
 \end{fcvref}
+}
+
+\begin{fcvlabel}[ln:defer:synchonize-rcu vs rcu-barrier]
+\begin{VerbatimN}[commandchars=\\\@\$]
+	do_something_1();			\lnlbl@ds1$
+	rcu_read_lock();			\lnlbl@rrl$
+	do_something_2();			\lnlbl@ds2$
+	call_rcu(&p->rh, f);			\lnlbl@cr$
+	do_something_3();			\lnlbl@ds3$
+	rcu_read_unlock();			\lnlbl@rrul$
+	do_something_4();			\lnlbl@ds4$
+	// f(&p->rh) invoked			\lnlbl@cb$
+	do_something_5();			\lnlbl@ds5$
+\end{VerbatimN}
+\end{fcvlabel}
 \caption{\tco{synchronize_rcu()} vs. \tco{rcu_barrier()}}
 \label{tab:defer:synchonize-rcu vs rcu-barrier}
-\end{table*}
+\end{table}
+
+	This distinction is illustrated by
+	\cref{tab:defer:synchonize-rcu vs rcu-barrier}, in which
+	the snippet at the bottom shows code being executed by a given CPU\@.
+	For simplicity, assume that no other CPU is executing
+	\co{rcu_read_lock()}, \co{rcu_read_unlock()}, or
+	\co{call_rcu()}.
 
-	\Cref{tab:defer:synchonize-rcu vs rcu-barrier}
-	shows how long each primitive must wait if invoked
+	The table shows how long each primitive must wait if invoked
 	concurrently with each of the \co{do_something_*()}
 	functions, with empty cells indicating that no
 	waiting is necessary.