Re: [PATCH -perfbook] defer/rcuusage: Fix minor nits

["Paul E. McKenney" <paulmck@kernel.org>]

On Mon, Dec 20, 2021 at 08:49:15PM +0900, Akira Yokosawa wrote:
> Signed-off-by: Akira Yokosawa <akiyks@gmail.com>
> ---
> Hi Paul,
> 
> In this patch, 1st and 2nd hunks are trivial typo fixes.
> 
> 3rd and 4th hunks remove "Code" and "Semantics" in paragraph titles,
> which look redundant to me.
> 
> Please feel free to pick whichever hunk you'd like.

Queued and pushed, thank you!  And yes, I did do a split "Walla Walla"
error on those paragraph titles, good catch.  (As the old saying in
this little piece of the world goes: "Walla Walla:  The town that was
so popular that they named it twice!")

							Thanx, Paul

>         Thanks, Akira
> --
>  defer/rcuusage.tex | 8 ++++----
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/defer/rcuusage.tex b/defer/rcuusage.tex
> index 7e154fac..3fbe73be 100644
> --- a/defer/rcuusage.tex
> +++ b/defer/rcuusage.tex
> @@ -273,7 +273,7 @@ the Linux kernel.
>  In this example, the \co{timer_stop} function uses
>  \co{synchronize_sched()} to ensure that all in-flight NMI
>  notifications have completed before freeing the associated resources.
> -A simplified version of this code is shown
> +A simplified version of this code is shown in
>  \cref{lst:defer:Using RCU to Wait for NMIs to Finish}.
>  
>  \begin{listing}
> @@ -324,7 +324,7 @@ region of memory.
>  \Clnrefrange{b}{e} define the \co{nmi_profile()} function,
>  which is called from within an NMI handler.
>  As such, it cannot be preempted, nor can it be interrupted by a normal
> -interrupts handler, however, it is still subject to delays due to cache misses,
> +interrupt handler, however, it is still subject to delays due to cache misses,
>  ECC errors, and cycle stealing by other hardware threads within the same
>  core.
>  \Clnref{rcu_deref} gets a local pointer to the profile buffer using the
> @@ -1367,7 +1367,7 @@ and \co{poll_state_synchronize_rcu()}), this situation is a major reason
>  for the rule of thumb that RCU be used in read-mostly situations.
>  
>  \paragraph{Code:
> -		 Reader-Writer Locking vs.\@ RCU Code}
> +		 Reader-Writer Locking vs.\@ RCU}
>  
>  In the best case, the conversion from reader-writer locking to RCU
>  is quite simple, as shown in
> @@ -1475,7 +1475,7 @@ may be found
>  elsewhere~\cite{NeilBrown2015PathnameLookup,NeilBrown2015RCUwalk}.
>  
>  \paragraph{Semantics:
> -		      Reader-Writer Locking vs.\@ RCU Semantics}
> +		      Reader-Writer Locking vs.\@ RCU}
>  
>  Reader-writer locking semantics can be roughly and informally summarized
>  by the following three temporal constraints:
> 
> base-commit: f52aad5df39cdd2fdddaa5dc9244789fd638bef8
> -- 
> 2.17.1
>