Re: [PATCH 1/2] count: fix typos

["Paul E. McKenney" <paulmck@linux.vnet.ibm.com>]

On Tue, Mar 08, 2016 at 08:42:31AM +0900, SeongJae Park wrote:
> This commit fix typos such as wrong spelling, missed or unnecessarily
> inserted words and characters in `COUNTING` section.

Could you please resend with your Signed-off-by?  Looks good otherwise.

							Thanx, Paul

> ---
>  count/count.tex | 20 ++++++++++----------
>  1 file changed, 10 insertions(+), 10 deletions(-)
> 
> diff --git a/count/count.tex b/count/count.tex
> index 83b695f..8f69a10 100644
> --- a/count/count.tex
> +++ b/count/count.tex
> @@ -672,7 +672,7 @@ at the beginning of this chapter.
>  	to reduce.
>  	However, the worst case is unchanged because although the
>  	counter \emph{could} move in either direction, the worst
> -	case is whenthe read operation completes immediately,
> +	case is when the read operation completes immediately,
>  	but then is delayed for $\Delta$ time units, during which
>  	time all the changes in the counter's value move it in
>  	the same direction, again giving us an absolute error
> @@ -851,7 +851,7 @@ comes at the cost of the additional thread running \co{eventual()}.
>  	the per-thread \co{counter} variables
>  	might need to be limited to 32 bits in order to sum them accurately,
>  	but with a 64-bit \co{global_count} variable to avoid overflow.
> -	In this case, it is necessary to zero the per-thead
> +	In this case, it is necessary to zero the per-thread
>  	\co{counter} variables periodically in order to avoid overflow.
>  	It is extremely important to note that this zeroing cannot
>  	be delayed too long or overflow of the smaller per-thread
> @@ -1648,7 +1648,7 @@ Then line~34 releases \co{gblcnt_mutex}, and line~35 returns success.
> 
>  Lines~38-50 show \co{read_count()}, which returns the aggregate value
>  of the counter.
> -It acquires \co{gblcnt_mutex} on line~43 and releases it on line 48,
> +It acquires \co{gblcnt_mutex} on line~43 and releases it on line~48,
>  excluding global operations from \co{add_count()} and \co{sub_count()},
>  and, as we will see, also excluding thread creation and exit.
>  Line~44 initializes local variable \co{sum} to the value of
> @@ -2262,7 +2262,7 @@ then line~25 returns failure.
> 
>  Otherwise, line~28 adds \co{delta} to the global counter, line~29
>  spreads counts to the local state if appropriate, line~30 releases
> -\co{gblcnt_mutex} (again, as noted earlier), and finally, line 31
> +\co{gblcnt_mutex} (again, as noted earlier), and finally, line~31
>  returns success.
> 
>  Lines~34-63 of
> @@ -2305,7 +2305,7 @@ Line~9 acquires \co{gblcnt_mutex} and line~16 releases it.
>  Line~10 initializes local variable \co{sum} to the value of
>  \co{globalcount}, and the loop spanning lines~11-15 adds the
>  per-thread counters to this sum, isolating each per-thread counter
> -using \co{split_ctrandmax} on line 13.
> +using \co{split_ctrandmax} on line~13.
>  Finally, line~17 returns the sum.
> 
>  \begin{figure}[tbp]
> @@ -2432,7 +2432,7 @@ line~30 subtracts this thread's \co{countermax} from \co{globalreserve}.
>  \QuickQuiz{}
>  	What stops a thread from simply refilling its
>  	\co{ctrandmax} variable immediately after
> -	\co{flush_local_count()} on line 14 of
> +	\co{flush_local_count()} on line~14 of
>  	Figure~\ref{fig:count:Atomic Limit Counter Utility Functions 1}
>  	empties it?
>  \QuickQuizAnswer{
> @@ -2449,7 +2449,7 @@ line~30 subtracts this thread's \co{countermax} from \co{globalreserve}.
>  	What prevents concurrent execution of the fastpath of either
>  	\co{add_count()} or \co{sub_count()} from interfering with
>  	the \co{ctrandmax} variable while
> -	\co{flush_local_count()} is accessing it on line 27 of
> +	\co{flush_local_count()} is accessing it on line~27 of
>  	Figure~\ref{fig:count:Atomic Limit Counter Utility Functions 1}
>  	empties it?
>  \QuickQuizAnswer{
> @@ -2542,7 +2542,7 @@ Even though per-thread state will now be manipulated only by the
>  corresponding thread, there will still need to be synchronization
>  with the signal handlers.
>  This synchronization is provided by the state machine shown in
> -Figure~\ref{fig:count:Signal-Theft State Machine}
> +Figure~\ref{fig:count:Signal-Theft State Machine}.
>  The state machine starts out in the IDLE state, and when \co{add_count()}
>  or \co{sub_count()} find that the combination of the local thread's count
>  and the global count cannot accommodate the request, the corresponding
> @@ -3576,7 +3576,7 @@ Summarizing the summary:
>  	counters' partitioned updates and non-partitioned reads), but also
>  	across time (as in
>  	Section~\ref{sec:count:Approximate Limit Counters}'s and
> -	Section~\ref{sec:count:Exact Limit Counters}'s and
> +	Section~\ref{sec:count:Exact Limit Counters}'s
>  	limit counters running fast when far from
>  	the limit, but slowly when close to the limit).
>  \item	Partitioning across time often batches updates locally
> @@ -3585,7 +3585,7 @@ Summarizing the summary:
>  	improving performance and scalability.
>  	All the algorithms shown in
>  	Tables~\ref{tab:count:Statistical Counter Performance on Power-6}
> -	and~\ref{tab:count:Limit Counter Performance on Power-6}?
> +	and~\ref{tab:count:Limit Counter Performance on Power-6}
>  	make heavy use of batching.
>  \item	Read-only code paths should remain read-only:  Spurious
>  	synchronization writes to shared memory kill performance
> -- 
> 1.9.1
>