On Tue, Mar 08, 2016 at 09:13:38AM +0900, SeongJae Park wrote:
> This commit fix typos such as wrong spelling, missed or unnecessarily
> inserted words and characters in `COUNTING` section.
>
> Signed-off-by: SeongJae Park <sj38.park@xxxxxxxxx>
Applied both, thank you!
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
>
--
To unsubscribe from this list: send the line "unsubscribe perfbook" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
