[PATCH] defer: Fix grammar issues across Chapter 9 text

[PATCH] defer: Fix grammar issues across Chapter 9 text

[Kunwu Chan]

Fix subject-verb agreement, singular/plural forms, pronoun agreement,
and countability in Chapter 9 prose.

These wording-only edits improve readability without changing
technical meaning.

Signed-off-by: Kunwu Chan <kunwu.chan@linux.dev>
---
 defer/defer.tex          |  2 +-
 defer/rcu.tex            |  2 +-
 defer/rcuapi.tex         |  2 +-
 defer/rcufundamental.tex |  2 +-
 defer/rcuusage.tex       |  4 ++--
 defer/whichtochoose.tex  | 10 +++++-----
 6 files changed, 11 insertions(+), 11 deletions(-)

diff --git a/defer/defer.tex b/defer/defer.tex
index eefb1215..3a24ee5d 100644
--- a/defer/defer.tex
+++ b/defer/defer.tex
@@ -87,7 +87,7 @@ interface~3, and address~17 to interface~7.
 This list will normally be searched frequently and updated rarely.
 In \cref{chp:Hardware and its Habits}
 we learned that the best ways to evade inconvenient laws of physics, such as
-the finite speed of light and the atomic nature of matter, is to
+the finite speed of light and the atomic nature of matter, are to
 either partition the data or to rely on read-mostly sharing.
 This chapter applies read-mostly sharing techniques to Pre-BSD packet
 routing.
diff --git a/defer/rcu.tex b/defer/rcu.tex
index 13078687..9d812d77 100644
--- a/defer/rcu.tex
+++ b/defer/rcu.tex
@@ -16,7 +16,7 @@ use explicit counters to defer actions that could disturb readers,
 which results in read-side contention and thus poor scalability.
 The hazard pointers covered by
 \cref{sec:defer:Hazard Pointers}
-uses implicit counters in the guise of per-thread lists of pointer.
+use implicit counters in the guise of per-thread lists of pointers.
 This avoids read-side contention, but requires readers to do stores and
 conditional branches, as well as either \IXhpl{full}{memory barrier}
 in read-side primitives or real-time-unfriendly \IXacrlpl{ipi} in
diff --git a/defer/rcuapi.tex b/defer/rcuapi.tex
index 4e231e5a..09e7c277 100644
--- a/defer/rcuapi.tex
+++ b/defer/rcuapi.tex
@@ -599,7 +599,7 @@ to reuse during the grace period that otherwise would have allowed them
 to be freed.
 Although this can be handled through careful use of flags that interact
 with the RCU callback queued by \co{call_rcu()}, this can be inconvenient
-and can waste CPU times due to the overhead of the doomed \co{call_rcu()}
+and can waste CPU time due to the overhead of the doomed \co{call_rcu()}
 invocations.
 
 In these cases, RCU's polled grace-period primitives can be helpful.
diff --git a/defer/rcufundamental.tex b/defer/rcufundamental.tex
index ccfe9133..604381a9 100644
--- a/defer/rcufundamental.tex
+++ b/defer/rcufundamental.tex
@@ -11,7 +11,7 @@ independent of any particular example or use case.
 People who prefer to live their lives very close to the actual code may
 wish to skip the underlying fundamentals presented in this section.
 
-The common use of RCU to protect linked data structure is comprised
+The common use of RCU to protect linked data structures is comprised
 of three fundamental mechanisms, the first being used for insertion,
 the second being used for deletion, and the third being used to allow
 readers to tolerate concurrent insertions and deletions.
diff --git a/defer/rcuusage.tex b/defer/rcuusage.tex
index 2bbd4cef..36939300 100644
--- a/defer/rcuusage.tex
+++ b/defer/rcuusage.tex
@@ -156,7 +156,7 @@ that of the ideal synchronization-free workload.
 	\cref{sec:cpu:Pipelined CPUs}
 	carefully already knew all of this!
 
-	These counter-intuitive results of course means that any
+	These counter-intuitive results of course mean that any
 	performance result on modern microprocessors must be subject to
 	some skepticism.
 	In theory, it really does not make sense to obtain performance
@@ -241,7 +241,7 @@ As noted in \cref{sec:defer:RCU Fundamentals}
 an important component
 of RCU is a way of waiting for RCU readers to finish.
 One of
-RCU's great strength is that it allows you to wait for each of
+RCU's great strengths is that it allows you to wait for each of
 thousands of different things to finish without having to explicitly
 track each and every one of them, and without incurring
 the performance degradation, scalability limitations, complex deadlock
diff --git a/defer/whichtochoose.tex b/defer/whichtochoose.tex
index a152b028..a11de412 100644
--- a/defer/whichtochoose.tex
+++ b/defer/whichtochoose.tex
@@ -102,8 +102,8 @@ and that there be sufficient pointers for each CPU or thread to
 track all the objects being referenced at any given time.
 Given that most hazard-pointer-based traversals require only a few
 hazard pointers, this is not normally a problem in practice.
-Of course, sequence locks provides no pointer-traversal protection,
-which is why it is normally used on static data.
+Of course, sequence locks provide no pointer-traversal protection,
+which is why they are normally used on static data.
 
 \QuickQuiz{
 	Why can't users dynamically allocate the hazard pointers as they
@@ -124,7 +124,7 @@ RCU readers must therefore be relatively short in order to avoid running
 the system out of memory, with special-purpose implementations such
 as SRCU, Tasks RCU, and Tasks Trace RCU being exceptions to this rule.
 Again, sequence locks provide no pointer-traversal protection,
-which is why it is normally used on static data.
+which is why they are normally used on static data.
 
 The ``Need for Traversal Retries'' row tells whether a new reference to
 a given object may be acquired unconditionally, as it can with RCU, or
@@ -319,7 +319,7 @@ Hazard pointers incur the overhead of a \IX{memory barrier}
 for each data element
 traversed, and sequence locks incur the overhead of a pair of memory barriers
 for each attempt to execute the critical section.
-The overhead of RCU implementations vary from nothing to that of a pair of
+The overhead of RCU implementations varies from nothing to that of a pair of
 memory barriers for each read-side critical section, thus providing RCU
 with the best performance, particularly for read-side critical sections
 that traverse many data elements.
@@ -622,7 +622,7 @@ Stjepan Glavina merged an epoch-based RCU implementation into the
 \co{crossbeam} set of concurrency-support ``crates'' for the Rust
 language~\cite{StjepanGlavina2018RustRCU}.
 
-Jason Donenfeld produced an RCU implementations as part of his port of
+Jason Donenfeld produced an RCU implementation as part of his port of
 WireGuard to Windows~NT kernel~\cite{JasonDonenfeld2021:WindowsNTwireguardRCU}.
 
 Finally, any garbage-collected concurrent language (not just Go!\@) gets
-- 
2.25.1

Re: [PATCH] defer: Fix grammar issues across Chapter 9 text

[Paul E. McKenney]

On Wed, Feb 25, 2026 at 08:44:24PM +0800, Kunwu Chan wrote:
> Fix subject-verb agreement, singular/plural forms, pronoun agreement,
> and countability in Chapter 9 prose.
> 
> These wording-only edits improve readability without changing
> technical meaning.
> 
> Signed-off-by: Kunwu Chan <kunwu.chan@linux.dev>

Again, good eyes and thank you!  I applied all three, with the exception of 
this hunk:

------------------------------------------------------------------------

diff --git a/defer/rcufundamental.tex b/defer/rcufundamental.tex
index 0c8c2e23..23bda66b 100644
--- a/defer/rcufundamental.tex
+++ b/defer/rcufundamental.tex
@@ -559,7 +559,7 @@ tolerable, they are in fact invisible.
 In such cases, RCU readers can be considered to be fully ordered with
 updaters, despite the fact that these readers might be executing the
 exact same sequence of machine instructions that would be executed by
-a single-threaded program, as hinted on
+a single-threaded program, as hinted at
 \cpageref{sec:defer:Mysteries RCU}.
 For example, referring back to
 \cref{lst:defer:Insertion and Deletion With Concurrent Readers}

------------------------------------------------------------------------

This one is one of the many strangenesses of English.  You might start
reading "at page 30", but you would find information "on page 30".  Or
am I misreading this?

							Thanx, Paul

> ---
>  defer/defer.tex          |  2 +-
>  defer/rcu.tex            |  2 +-
>  defer/rcuapi.tex         |  2 +-
>  defer/rcufundamental.tex |  2 +-
>  defer/rcuusage.tex       |  4 ++--
>  defer/whichtochoose.tex  | 10 +++++-----
>  6 files changed, 11 insertions(+), 11 deletions(-)
> 
> diff --git a/defer/defer.tex b/defer/defer.tex
> index eefb1215..3a24ee5d 100644
> --- a/defer/defer.tex
> +++ b/defer/defer.tex
> @@ -87,7 +87,7 @@ interface~3, and address~17 to interface~7.
>  This list will normally be searched frequently and updated rarely.
>  In \cref{chp:Hardware and its Habits}
>  we learned that the best ways to evade inconvenient laws of physics, such as
> -the finite speed of light and the atomic nature of matter, is to
> +the finite speed of light and the atomic nature of matter, are to
>  either partition the data or to rely on read-mostly sharing.
>  This chapter applies read-mostly sharing techniques to Pre-BSD packet
>  routing.
> diff --git a/defer/rcu.tex b/defer/rcu.tex
> index 13078687..9d812d77 100644
> --- a/defer/rcu.tex
> +++ b/defer/rcu.tex
> @@ -16,7 +16,7 @@ use explicit counters to defer actions that could disturb readers,
>  which results in read-side contention and thus poor scalability.
>  The hazard pointers covered by
>  \cref{sec:defer:Hazard Pointers}
> -uses implicit counters in the guise of per-thread lists of pointer.
> +use implicit counters in the guise of per-thread lists of pointers.
>  This avoids read-side contention, but requires readers to do stores and
>  conditional branches, as well as either \IXhpl{full}{memory barrier}
>  in read-side primitives or real-time-unfriendly \IXacrlpl{ipi} in
> diff --git a/defer/rcuapi.tex b/defer/rcuapi.tex
> index 4e231e5a..09e7c277 100644
> --- a/defer/rcuapi.tex
> +++ b/defer/rcuapi.tex
> @@ -599,7 +599,7 @@ to reuse during the grace period that otherwise would have allowed them
>  to be freed.
>  Although this can be handled through careful use of flags that interact
>  with the RCU callback queued by \co{call_rcu()}, this can be inconvenient
> -and can waste CPU times due to the overhead of the doomed \co{call_rcu()}
> +and can waste CPU time due to the overhead of the doomed \co{call_rcu()}
>  invocations.
>  
>  In these cases, RCU's polled grace-period primitives can be helpful.
> diff --git a/defer/rcufundamental.tex b/defer/rcufundamental.tex
> index ccfe9133..604381a9 100644
> --- a/defer/rcufundamental.tex
> +++ b/defer/rcufundamental.tex
> @@ -11,7 +11,7 @@ independent of any particular example or use case.
>  People who prefer to live their lives very close to the actual code may
>  wish to skip the underlying fundamentals presented in this section.
>  
> -The common use of RCU to protect linked data structure is comprised
> +The common use of RCU to protect linked data structures is comprised
>  of three fundamental mechanisms, the first being used for insertion,
>  the second being used for deletion, and the third being used to allow
>  readers to tolerate concurrent insertions and deletions.
> diff --git a/defer/rcuusage.tex b/defer/rcuusage.tex
> index 2bbd4cef..36939300 100644
> --- a/defer/rcuusage.tex
> +++ b/defer/rcuusage.tex
> @@ -156,7 +156,7 @@ that of the ideal synchronization-free workload.
>  	\cref{sec:cpu:Pipelined CPUs}
>  	carefully already knew all of this!
>  
> -	These counter-intuitive results of course means that any
> +	These counter-intuitive results of course mean that any
>  	performance result on modern microprocessors must be subject to
>  	some skepticism.
>  	In theory, it really does not make sense to obtain performance
> @@ -241,7 +241,7 @@ As noted in \cref{sec:defer:RCU Fundamentals}
>  an important component
>  of RCU is a way of waiting for RCU readers to finish.
>  One of
> -RCU's great strength is that it allows you to wait for each of
> +RCU's great strengths is that it allows you to wait for each of
>  thousands of different things to finish without having to explicitly
>  track each and every one of them, and without incurring
>  the performance degradation, scalability limitations, complex deadlock
> diff --git a/defer/whichtochoose.tex b/defer/whichtochoose.tex
> index a152b028..a11de412 100644
> --- a/defer/whichtochoose.tex
> +++ b/defer/whichtochoose.tex
> @@ -102,8 +102,8 @@ and that there be sufficient pointers for each CPU or thread to
>  track all the objects being referenced at any given time.
>  Given that most hazard-pointer-based traversals require only a few
>  hazard pointers, this is not normally a problem in practice.
> -Of course, sequence locks provides no pointer-traversal protection,
> -which is why it is normally used on static data.
> +Of course, sequence locks provide no pointer-traversal protection,
> +which is why they are normally used on static data.
>  
>  \QuickQuiz{
>  	Why can't users dynamically allocate the hazard pointers as they
> @@ -124,7 +124,7 @@ RCU readers must therefore be relatively short in order to avoid running
>  the system out of memory, with special-purpose implementations such
>  as SRCU, Tasks RCU, and Tasks Trace RCU being exceptions to this rule.
>  Again, sequence locks provide no pointer-traversal protection,
> -which is why it is normally used on static data.
> +which is why they are normally used on static data.
>  
>  The ``Need for Traversal Retries'' row tells whether a new reference to
>  a given object may be acquired unconditionally, as it can with RCU, or
> @@ -319,7 +319,7 @@ Hazard pointers incur the overhead of a \IX{memory barrier}
>  for each data element
>  traversed, and sequence locks incur the overhead of a pair of memory barriers
>  for each attempt to execute the critical section.
> -The overhead of RCU implementations vary from nothing to that of a pair of
> +The overhead of RCU implementations varies from nothing to that of a pair of
>  memory barriers for each read-side critical section, thus providing RCU
>  with the best performance, particularly for read-side critical sections
>  that traverse many data elements.
> @@ -622,7 +622,7 @@ Stjepan Glavina merged an epoch-based RCU implementation into the
>  \co{crossbeam} set of concurrency-support ``crates'' for the Rust
>  language~\cite{StjepanGlavina2018RustRCU}.
>  
> -Jason Donenfeld produced an RCU implementations as part of his port of
> +Jason Donenfeld produced an RCU implementation as part of his port of
>  WireGuard to Windows~NT kernel~\cite{JasonDonenfeld2021:WindowsNTwireguardRCU}.
>  
>  Finally, any garbage-collected concurrent language (not just Go!\@) gets
> -- 
> 2.25.1
> 

Re: [PATCH] defer: Fix grammar issues across Chapter 9 text

[Kunwu Chan]

February 26, 2026 at 9:02 AM, "Paul E. McKenney" <paulmck@kernel.org mailto:paulmck@kernel.org?to=%22Paul%20E.%20McKenney%22%20%3Cpaulmck%40kernel.org%3E > wrote:


> 
> On Wed, Feb 25, 2026 at 08:44:24PM +0800, Kunwu Chan wrote:
> 
> > 
> > Fix subject-verb agreement, singular/plural forms, pronoun agreement,
> >  and countability in Chapter 9 prose.
> >  
> >  These wording-only edits improve readability without changing
> >  technical meaning.
> >  
> >  Signed-off-by: Kunwu Chan <kunwu.chan@linux.dev>
> > 
> Again, good eyes and thank you! I applied all three, with the exception of 
> this hunk:
> 
> ------------------------------------------------------------------------
> 
> diff --git a/defer/rcufundamental.tex b/defer/rcufundamental.tex
> index 0c8c2e23..23bda66b 100644
> --- a/defer/rcufundamental.tex
> +++ b/defer/rcufundamental.tex
> @@ -559,7 +559,7 @@ tolerable, they are in fact invisible.
>  In such cases, RCU readers can be considered to be fully ordered with
>  updaters, despite the fact that these readers might be executing the
>  exact same sequence of machine instructions that would be executed by
> -a single-threaded program, as hinted on
> +a single-threaded program, as hinted at
>  \cpageref{sec:defer:Mysteries RCU}.
>  For example, referring back to
>  \cref{lst:defer:Insertion and Deletion With Concurrent Readers}
> 
> ------------------------------------------------------------------------
> 
> This one is one of the many strangenesses of English. You might start
> reading "at page 30", but you would find information "on page 30". Or
> am I misreading this?
> 
>  Thanx, Paul
> 
Makes sense — both forms seem to be used.

I originally changed it based on my understanding of the usual phrasing,
but I also noticed the perfbook currently uses both "hinted at" and "hinted on".
I can send a small follow-up patch to make them consistent if that sounds good.

Thanx, Kunwu

> > 
> > ---
> >  defer/defer.tex | 2 +-
> >  defer/rcu.tex | 2 +-
> >  defer/rcuapi.tex | 2 +-
> >  defer/rcufundamental.tex | 2 +-
> >  defer/rcuusage.tex | 4 ++--
> >  defer/whichtochoose.tex | 10 +++++-----
> >  6 files changed, 11 insertions(+), 11 deletions(-)
> >  
> >  diff --git a/defer/defer.tex b/defer/defer.tex
> >  index eefb1215..3a24ee5d 100644
> >  --- a/defer/defer.tex
> >  +++ b/defer/defer.tex
> >  @@ -87,7 +87,7 @@ interface~3, and address~17 to interface~7.
> >  This list will normally be searched frequently and updated rarely.
> >  In \cref{chp:Hardware and its Habits}
> >  we learned that the best ways to evade inconvenient laws of physics, such as
> >  -the finite speed of light and the atomic nature of matter, is to
> >  +the finite speed of light and the atomic nature of matter, are to
> >  either partition the data or to rely on read-mostly sharing.
> >  This chapter applies read-mostly sharing techniques to Pre-BSD packet
> >  routing.
> >  diff --git a/defer/rcu.tex b/defer/rcu.tex
> >  index 13078687..9d812d77 100644
> >  --- a/defer/rcu.tex
> >  +++ b/defer/rcu.tex
> >  @@ -16,7 +16,7 @@ use explicit counters to defer actions that could disturb readers,
> >  which results in read-side contention and thus poor scalability.
> >  The hazard pointers covered by
> >  \cref{sec:defer:Hazard Pointers}
> >  -uses implicit counters in the guise of per-thread lists of pointer.
> >  +use implicit counters in the guise of per-thread lists of pointers.
> >  This avoids read-side contention, but requires readers to do stores and
> >  conditional branches, as well as either \IXhpl{full}{memory barrier}
> >  in read-side primitives or real-time-unfriendly \IXacrlpl{ipi} in
> >  diff --git a/defer/rcuapi.tex b/defer/rcuapi.tex
> >  index 4e231e5a..09e7c277 100644
> >  --- a/defer/rcuapi.tex
> >  +++ b/defer/rcuapi.tex
> >  @@ -599,7 +599,7 @@ to reuse during the grace period that otherwise would have allowed them
> >  to be freed.
> >  Although this can be handled through careful use of flags that interact
> >  with the RCU callback queued by \co{call_rcu()}, this can be inconvenient
> >  -and can waste CPU times due to the overhead of the doomed \co{call_rcu()}
> >  +and can waste CPU time due to the overhead of the doomed \co{call_rcu()}
> >  invocations.
> >  
> >  In these cases, RCU's polled grace-period primitives can be helpful.
> >  diff --git a/defer/rcufundamental.tex b/defer/rcufundamental.tex
> >  index ccfe9133..604381a9 100644
> >  --- a/defer/rcufundamental.tex
> >  +++ b/defer/rcufundamental.tex
> >  @@ -11,7 +11,7 @@ independent of any particular example or use case.
> >  People who prefer to live their lives very close to the actual code may
> >  wish to skip the underlying fundamentals presented in this section.
> >  
> >  -The common use of RCU to protect linked data structure is comprised
> >  +The common use of RCU to protect linked data structures is comprised
> >  of three fundamental mechanisms, the first being used for insertion,
> >  the second being used for deletion, and the third being used to allow
> >  readers to tolerate concurrent insertions and deletions.
> >  diff --git a/defer/rcuusage.tex b/defer/rcuusage.tex
> >  index 2bbd4cef..36939300 100644
> >  --- a/defer/rcuusage.tex
> >  +++ b/defer/rcuusage.tex
> >  @@ -156,7 +156,7 @@ that of the ideal synchronization-free workload.
> >  \cref{sec:cpu:Pipelined CPUs}
> >  carefully already knew all of this!
> >  
> >  - These counter-intuitive results of course means that any
> >  + These counter-intuitive results of course mean that any
> >  performance result on modern microprocessors must be subject to
> >  some skepticism.
> >  In theory, it really does not make sense to obtain performance
> >  @@ -241,7 +241,7 @@ As noted in \cref{sec:defer:RCU Fundamentals}
> >  an important component
> >  of RCU is a way of waiting for RCU readers to finish.
> >  One of
> >  -RCU's great strength is that it allows you to wait for each of
> >  +RCU's great strengths is that it allows you to wait for each of
> >  thousands of different things to finish without having to explicitly
> >  track each and every one of them, and without incurring
> >  the performance degradation, scalability limitations, complex deadlock
> >  diff --git a/defer/whichtochoose.tex b/defer/whichtochoose.tex
> >  index a152b028..a11de412 100644
> >  --- a/defer/whichtochoose.tex
> >  +++ b/defer/whichtochoose.tex
> >  @@ -102,8 +102,8 @@ and that there be sufficient pointers for each CPU or thread to
> >  track all the objects being referenced at any given time.
> >  Given that most hazard-pointer-based traversals require only a few
> >  hazard pointers, this is not normally a problem in practice.
> >  -Of course, sequence locks provides no pointer-traversal protection,
> >  -which is why it is normally used on static data.
> >  +Of course, sequence locks provide no pointer-traversal protection,
> >  +which is why they are normally used on static data.
> >  
> >  \QuickQuiz{
> >  Why can't users dynamically allocate the hazard pointers as they
> >  @@ -124,7 +124,7 @@ RCU readers must therefore be relatively short in order to avoid running
> >  the system out of memory, with special-purpose implementations such
> >  as SRCU, Tasks RCU, and Tasks Trace RCU being exceptions to this rule.
> >  Again, sequence locks provide no pointer-traversal protection,
> >  -which is why it is normally used on static data.
> >  +which is why they are normally used on static data.
> >  
> >  The ``Need for Traversal Retries'' row tells whether a new reference to
> >  a given object may be acquired unconditionally, as it can with RCU, or
> >  @@ -319,7 +319,7 @@ Hazard pointers incur the overhead of a \IX{memory barrier}
> >  for each data element
> >  traversed, and sequence locks incur the overhead of a pair of memory barriers
> >  for each attempt to execute the critical section.
> >  -The overhead of RCU implementations vary from nothing to that of a pair of
> >  +The overhead of RCU implementations varies from nothing to that of a pair of
> >  memory barriers for each read-side critical section, thus providing RCU
> >  with the best performance, particularly for read-side critical sections
> >  that traverse many data elements.
> >  @@ -622,7 +622,7 @@ Stjepan Glavina merged an epoch-based RCU implementation into the
> >  \co{crossbeam} set of concurrency-support ``crates'' for the Rust
> >  language~\cite{StjepanGlavina2018RustRCU}.
> >  
> >  -Jason Donenfeld produced an RCU implementations as part of his port of
> >  +Jason Donenfeld produced an RCU implementation as part of his port of
> >  WireGuard to Windows~NT kernel~\cite{JasonDonenfeld2021:WindowsNTwireguardRCU}.
> >  
> >  Finally, any garbage-collected concurrent language (not just Go!\@) gets
> >  -- 
> >  2.25.1
> >
>

Re: [PATCH] defer: Fix grammar issues across Chapter 9 text

[Paul E. McKenney]

On Thu, Feb 26, 2026 at 02:49:16AM +0000, Kunwu Chan wrote:
> February 26, 2026 at 9:02 AM, "Paul E. McKenney" <paulmck@kernel.org mailto:paulmck@kernel.org?to=%22Paul%20E.%20McKenney%22%20%3Cpaulmck%40kernel.org%3E > wrote:
> 
> 
> > 
> > On Wed, Feb 25, 2026 at 08:44:24PM +0800, Kunwu Chan wrote:
> > 
> > > 
> > > Fix subject-verb agreement, singular/plural forms, pronoun agreement,
> > >  and countability in Chapter 9 prose.
> > >  
> > >  These wording-only edits improve readability without changing
> > >  technical meaning.
> > >  
> > >  Signed-off-by: Kunwu Chan <kunwu.chan@linux.dev>
> > > 
> > Again, good eyes and thank you! I applied all three, with the exception of 
> > this hunk:
> > 
> > ------------------------------------------------------------------------
> > 
> > diff --git a/defer/rcufundamental.tex b/defer/rcufundamental.tex
> > index 0c8c2e23..23bda66b 100644
> > --- a/defer/rcufundamental.tex
> > +++ b/defer/rcufundamental.tex
> > @@ -559,7 +559,7 @@ tolerable, they are in fact invisible.
> >  In such cases, RCU readers can be considered to be fully ordered with
> >  updaters, despite the fact that these readers might be executing the
> >  exact same sequence of machine instructions that would be executed by
> > -a single-threaded program, as hinted on
> > +a single-threaded program, as hinted at
> >  \cpageref{sec:defer:Mysteries RCU}.
> >  For example, referring back to
> >  \cref{lst:defer:Insertion and Deletion With Concurrent Readers}
> > 
> > ------------------------------------------------------------------------
> > 
> > This one is one of the many strangenesses of English. You might start
> > reading "at page 30", but you would find information "on page 30". Or
> > am I misreading this?
> > 
> >  Thanx, Paul
> > 
> Makes sense — both forms seem to be used.
> 
> I originally changed it based on my understanding of the usual phrasing,
> but I also noticed the perfbook currently uses both "hinted at" and "hinted on".
> I can send a small follow-up patch to make them consistent if that sounds good.

Good point!

But when I took a quick look, I found reasons for the divergence.
Maybe the best way forward is for you to send me a list of (say) 25 of
them, and for me to explain why what is there is correct on the one hand
or to not the needed change on the other.

Then you could use that information to create the patch for those
needing change.

Seem reasonable?

							Thanx, Paul

> Thanx, Kunwu
> 
> > > 
> > > ---
> > >  defer/defer.tex | 2 +-
> > >  defer/rcu.tex | 2 +-
> > >  defer/rcuapi.tex | 2 +-
> > >  defer/rcufundamental.tex | 2 +-
> > >  defer/rcuusage.tex | 4 ++--
> > >  defer/whichtochoose.tex | 10 +++++-----
> > >  6 files changed, 11 insertions(+), 11 deletions(-)
> > >  
> > >  diff --git a/defer/defer.tex b/defer/defer.tex
> > >  index eefb1215..3a24ee5d 100644
> > >  --- a/defer/defer.tex
> > >  +++ b/defer/defer.tex
> > >  @@ -87,7 +87,7 @@ interface~3, and address~17 to interface~7.
> > >  This list will normally be searched frequently and updated rarely.
> > >  In \cref{chp:Hardware and its Habits}
> > >  we learned that the best ways to evade inconvenient laws of physics, such as
> > >  -the finite speed of light and the atomic nature of matter, is to
> > >  +the finite speed of light and the atomic nature of matter, are to
> > >  either partition the data or to rely on read-mostly sharing.
> > >  This chapter applies read-mostly sharing techniques to Pre-BSD packet
> > >  routing.
> > >  diff --git a/defer/rcu.tex b/defer/rcu.tex
> > >  index 13078687..9d812d77 100644
> > >  --- a/defer/rcu.tex
> > >  +++ b/defer/rcu.tex
> > >  @@ -16,7 +16,7 @@ use explicit counters to defer actions that could disturb readers,
> > >  which results in read-side contention and thus poor scalability.
> > >  The hazard pointers covered by
> > >  \cref{sec:defer:Hazard Pointers}
> > >  -uses implicit counters in the guise of per-thread lists of pointer.
> > >  +use implicit counters in the guise of per-thread lists of pointers.
> > >  This avoids read-side contention, but requires readers to do stores and
> > >  conditional branches, as well as either \IXhpl{full}{memory barrier}
> > >  in read-side primitives or real-time-unfriendly \IXacrlpl{ipi} in
> > >  diff --git a/defer/rcuapi.tex b/defer/rcuapi.tex
> > >  index 4e231e5a..09e7c277 100644
> > >  --- a/defer/rcuapi.tex
> > >  +++ b/defer/rcuapi.tex
> > >  @@ -599,7 +599,7 @@ to reuse during the grace period that otherwise would have allowed them
> > >  to be freed.
> > >  Although this can be handled through careful use of flags that interact
> > >  with the RCU callback queued by \co{call_rcu()}, this can be inconvenient
> > >  -and can waste CPU times due to the overhead of the doomed \co{call_rcu()}
> > >  +and can waste CPU time due to the overhead of the doomed \co{call_rcu()}
> > >  invocations.
> > >  
> > >  In these cases, RCU's polled grace-period primitives can be helpful.
> > >  diff --git a/defer/rcufundamental.tex b/defer/rcufundamental.tex
> > >  index ccfe9133..604381a9 100644
> > >  --- a/defer/rcufundamental.tex
> > >  +++ b/defer/rcufundamental.tex
> > >  @@ -11,7 +11,7 @@ independent of any particular example or use case.
> > >  People who prefer to live their lives very close to the actual code may
> > >  wish to skip the underlying fundamentals presented in this section.
> > >  
> > >  -The common use of RCU to protect linked data structure is comprised
> > >  +The common use of RCU to protect linked data structures is comprised
> > >  of three fundamental mechanisms, the first being used for insertion,
> > >  the second being used for deletion, and the third being used to allow
> > >  readers to tolerate concurrent insertions and deletions.
> > >  diff --git a/defer/rcuusage.tex b/defer/rcuusage.tex
> > >  index 2bbd4cef..36939300 100644
> > >  --- a/defer/rcuusage.tex
> > >  +++ b/defer/rcuusage.tex
> > >  @@ -156,7 +156,7 @@ that of the ideal synchronization-free workload.
> > >  \cref{sec:cpu:Pipelined CPUs}
> > >  carefully already knew all of this!
> > >  
> > >  - These counter-intuitive results of course means that any
> > >  + These counter-intuitive results of course mean that any
> > >  performance result on modern microprocessors must be subject to
> > >  some skepticism.
> > >  In theory, it really does not make sense to obtain performance
> > >  @@ -241,7 +241,7 @@ As noted in \cref{sec:defer:RCU Fundamentals}
> > >  an important component
> > >  of RCU is a way of waiting for RCU readers to finish.
> > >  One of
> > >  -RCU's great strength is that it allows you to wait for each of
> > >  +RCU's great strengths is that it allows you to wait for each of
> > >  thousands of different things to finish without having to explicitly
> > >  track each and every one of them, and without incurring
> > >  the performance degradation, scalability limitations, complex deadlock
> > >  diff --git a/defer/whichtochoose.tex b/defer/whichtochoose.tex
> > >  index a152b028..a11de412 100644
> > >  --- a/defer/whichtochoose.tex
> > >  +++ b/defer/whichtochoose.tex
> > >  @@ -102,8 +102,8 @@ and that there be sufficient pointers for each CPU or thread to
> > >  track all the objects being referenced at any given time.
> > >  Given that most hazard-pointer-based traversals require only a few
> > >  hazard pointers, this is not normally a problem in practice.
> > >  -Of course, sequence locks provides no pointer-traversal protection,
> > >  -which is why it is normally used on static data.
> > >  +Of course, sequence locks provide no pointer-traversal protection,
> > >  +which is why they are normally used on static data.
> > >  
> > >  \QuickQuiz{
> > >  Why can't users dynamically allocate the hazard pointers as they
> > >  @@ -124,7 +124,7 @@ RCU readers must therefore be relatively short in order to avoid running
> > >  the system out of memory, with special-purpose implementations such
> > >  as SRCU, Tasks RCU, and Tasks Trace RCU being exceptions to this rule.
> > >  Again, sequence locks provide no pointer-traversal protection,
> > >  -which is why it is normally used on static data.
> > >  +which is why they are normally used on static data.
> > >  
> > >  The ``Need for Traversal Retries'' row tells whether a new reference to
> > >  a given object may be acquired unconditionally, as it can with RCU, or
> > >  @@ -319,7 +319,7 @@ Hazard pointers incur the overhead of a \IX{memory barrier}
> > >  for each data element
> > >  traversed, and sequence locks incur the overhead of a pair of memory barriers
> > >  for each attempt to execute the critical section.
> > >  -The overhead of RCU implementations vary from nothing to that of a pair of
> > >  +The overhead of RCU implementations varies from nothing to that of a pair of
> > >  memory barriers for each read-side critical section, thus providing RCU
> > >  with the best performance, particularly for read-side critical sections
> > >  that traverse many data elements.
> > >  @@ -622,7 +622,7 @@ Stjepan Glavina merged an epoch-based RCU implementation into the
> > >  \co{crossbeam} set of concurrency-support ``crates'' for the Rust
> > >  language~\cite{StjepanGlavina2018RustRCU}.
> > >  
> > >  -Jason Donenfeld produced an RCU implementations as part of his port of
> > >  +Jason Donenfeld produced an RCU implementation as part of his port of
> > >  WireGuard to Windows~NT kernel~\cite{JasonDonenfeld2021:WindowsNTwireguardRCU}.
> > >  
> > >  Finally, any garbage-collected concurrent language (not just Go!\@) gets
> > >  -- 
> > >  2.25.1
> > >
> >

Re: [PATCH] defer: Fix grammar issues across Chapter 9 text

[Kunwu Chan]

February 27, 2026 at 3:09 AM, "Paul E. McKenney" <paulmck@kernel.org mailto:paulmck@kernel.org?to=%22Paul%20E.%20McKenney%22%20%3Cpaulmck%40kernel.org%3E > wrote:


> 
> On Thu, Feb 26, 2026 at 02:49:16AM +0000, Kunwu Chan wrote:
> 
> > 
> > February 26, 2026 at 9:02 AM, "Paul E. McKenney" <paulmck@kernel.org mailto:paulmck@kernel.org?to=%22Paul%20E.%20McKenney%22%20%3Cpaulmck%40kernel.org%3E > wrote:
> >  
> >  
> >  
> >  On Wed, Feb 25, 2026 at 08:44:24PM +0800, Kunwu Chan wrote:
> >  
> >  > 
> >  > Fix subject-verb agreement, singular/plural forms, pronoun agreement,
> >  > and countability in Chapter 9 prose.
> >  > 
> >  > These wording-only edits improve readability without changing
> >  > technical meaning.
> >  > 
> >  > Signed-off-by: Kunwu Chan <kunwu.chan@linux.dev>
> >  > 
> >  Again, good eyes and thank you! I applied all three, with the exception of 
> >  this hunk:
> >  
> >  ------------------------------------------------------------------------
> >  
> >  diff --git a/defer/rcufundamental.tex b/defer/rcufundamental.tex
> >  index 0c8c2e23..23bda66b 100644
> >  --- a/defer/rcufundamental.tex
> >  +++ b/defer/rcufundamental.tex
> >  @@ -559,7 +559,7 @@ tolerable, they are in fact invisible.
> >  In such cases, RCU readers can be considered to be fully ordered with
> >  updaters, despite the fact that these readers might be executing the
> >  exact same sequence of machine instructions that would be executed by
> >  -a single-threaded program, as hinted on
> >  +a single-threaded program, as hinted at
> >  \cpageref{sec:defer:Mysteries RCU}.
> >  For example, referring back to
> >  \cref{lst:defer:Insertion and Deletion With Concurrent Readers}
> >  
> >  ------------------------------------------------------------------------
> >  
> >  This one is one of the many strangenesses of English. You might start
> >  reading "at page 30", but you would find information "on page 30". Or
> >  am I misreading this?
> >  
> >  Thanx, Paul
> >  
> >  Makes sense — both forms seem to be used.
> >  
> >  I originally changed it based on my understanding of the usual phrasing,
> >  but I also noticed the perfbook currently uses both "hinted at" and "hinted on".
> >  I can send a small follow-up patch to make them consistent if that sounds good.
> > 
> Good point!
> 
> But when I took a quick look, I found reasons for the divergence.
> Maybe the best way forward is for you to send me a list of (say) 25 of
> them, and for me to explain why what is there is correct on the one hand
> or to not the needed change on the other.
> 
> Then you could use that information to create the patch for those
> needing change.
> 
> Seem reasonable?
> 
>  Thanx, Paul
> 
Hi Paul,

Sounds good. I went through the current PDF and gathered the occurrences 
of "hinted at/on" that I could find. Here is the list for review:

Using PDF file: perfbook.2025.12.18a.pdf.

1) PDF location:
   p.98 (PDF page 110/686), Chapter 6 (Beyond Partitioning)
   Source location: SMPdesign/beyond.tex (line 14)

   “This chapter has discussed how data partitioning can be used to
   design simple linearly scalable parallel programs.
   \Cref{sec:SMPdesign:Data Ownership} hinted at the possibilities of
   data replication, which will be used to great effect in
   \cref{sec:defer:Read-Copy Update (RCU)}.”

2) PDF location:
   p.142 (PDF page 154/686), Chapter 9.4 (Sequence Locks)
   Source location: defer/seqlock.tex (lines 411–416)

   “As hinted on
   \cpageref{sec:defer:Mysteries sequence locking},
   both the read-side and write-side critical sections of a sequence
   lock can be thought of as transactions, and sequence locking
   therefore can be thought of as a limited form of transactional
   memory, which will be discussed in
   \cref{sec:future:Transactional Memory}.”

3) PDF location:
   p.155 (PDF page 167/686), Chapter 9.5 (RCU)
   Source location: defer/rcufundamental.tex (lines 559–563)

   “In such cases, RCU readers can be considered to be fully ordered with
   updaters, despite the fact that these readers might be executing the
   exact same sequence of machine instructions that would be executed by
   a single-threaded program, as hinted on
   \cpageref{sec:defer:Mysteries RCU}.”

4) PDF location:
   p.184 (PDF page 196/686), Chapter 9.5.4.12 area
   Source location: defer/rcuusage.tex (lines 2052–2054)

   “And so it is that RCU's use cases are conceptually more complex than
   is RCU itself, as hinted on
   \cpageref{sec:defer:Mysteries RCU Use Cases}.”

5) PDF location:
   p.533 (PDF page 545/686), Quick Quiz answers area
   Source location: defer/rcuintro.tex (lines 141–145)

   “As hinted at in
   \cref{sec:cpu:Hardware Optimizations,sec:cpu:Hardware Free Lunch?},
   speed-of-light delays mean that a computer's data is always stale
   compared to whatever external reality that data is intended to model.”

Please let me know which ones you’d prefer to keep as-is and 
which should be adjusted, and I’ll prepare a patch accordingly.


Thanx, Kunwu

> > 
> > Thanx, Kunwu
> >  
> >  > 
> >  > ---
> >  > defer/defer.tex | 2 +-
> >  > defer/rcu.tex | 2 +-
> >  > defer/rcuapi.tex | 2 +-
> >  > defer/rcufundamental.tex | 2 +-
> >  > defer/rcuusage.tex | 4 ++--
> >  > defer/whichtochoose.tex | 10 +++++-----
> >  > 6 files changed, 11 insertions(+), 11 deletions(-)
> >  > 
> >  > diff --git a/defer/defer.tex b/defer/defer.tex
> >  > index eefb1215..3a24ee5d 100644
> >  > --- a/defer/defer.tex
> >  > +++ b/defer/defer.tex
> >  > @@ -87,7 +87,7 @@ interface~3, and address~17 to interface~7.
> >  > This list will normally be searched frequently and updated rarely.
> >  > In \cref{chp:Hardware and its Habits}
> >  > we learned that the best ways to evade inconvenient laws of physics, such as
> >  > -the finite speed of light and the atomic nature of matter, is to
> >  > +the finite speed of light and the atomic nature of matter, are to
> >  > either partition the data or to rely on read-mostly sharing.
> >  > This chapter applies read-mostly sharing techniques to Pre-BSD packet
> >  > routing.
> >  > diff --git a/defer/rcu.tex b/defer/rcu.tex
> >  > index 13078687..9d812d77 100644
> >  > --- a/defer/rcu.tex
> >  > +++ b/defer/rcu.tex
> >  > @@ -16,7 +16,7 @@ use explicit counters to defer actions that could disturb readers,
> >  > which results in read-side contention and thus poor scalability.
> >  > The hazard pointers covered by
> >  > \cref{sec:defer:Hazard Pointers}
> >  > -uses implicit counters in the guise of per-thread lists of pointer.
> >  > +use implicit counters in the guise of per-thread lists of pointers.
> >  > This avoids read-side contention, but requires readers to do stores and
> >  > conditional branches, as well as either \IXhpl{full}{memory barrier}
> >  > in read-side primitives or real-time-unfriendly \IXacrlpl{ipi} in
> >  > diff --git a/defer/rcuapi.tex b/defer/rcuapi.tex
> >  > index 4e231e5a..09e7c277 100644
> >  > --- a/defer/rcuapi.tex
> >  > +++ b/defer/rcuapi.tex
> >  > @@ -599,7 +599,7 @@ to reuse during the grace period that otherwise would have allowed them
> >  > to be freed.
> >  > Although this can be handled through careful use of flags that interact
> >  > with the RCU callback queued by \co{call_rcu()}, this can be inconvenient
> >  > -and can waste CPU times due to the overhead of the doomed \co{call_rcu()}
> >  > +and can waste CPU time due to the overhead of the doomed \co{call_rcu()}
> >  > invocations.
> >  > 
> >  > In these cases, RCU's polled grace-period primitives can be helpful.
> >  > diff --git a/defer/rcufundamental.tex b/defer/rcufundamental.tex
> >  > index ccfe9133..604381a9 100644
> >  > --- a/defer/rcufundamental.tex
> >  > +++ b/defer/rcufundamental.tex
> >  > @@ -11,7 +11,7 @@ independent of any particular example or use case.
> >  > People who prefer to live their lives very close to the actual code may
> >  > wish to skip the underlying fundamentals presented in this section.
> >  > 
> >  > -The common use of RCU to protect linked data structure is comprised
> >  > +The common use of RCU to protect linked data structures is comprised
> >  > of three fundamental mechanisms, the first being used for insertion,
> >  > the second being used for deletion, and the third being used to allow
> >  > readers to tolerate concurrent insertions and deletions.
> >  > diff --git a/defer/rcuusage.tex b/defer/rcuusage.tex
> >  > index 2bbd4cef..36939300 100644
> >  > --- a/defer/rcuusage.tex
> >  > +++ b/defer/rcuusage.tex
> >  > @@ -156,7 +156,7 @@ that of the ideal synchronization-free workload.
> >  > \cref{sec:cpu:Pipelined CPUs}
> >  > carefully already knew all of this!
> >  > 
> >  > - These counter-intuitive results of course means that any
> >  > + These counter-intuitive results of course mean that any
> >  > performance result on modern microprocessors must be subject to
> >  > some skepticism.
> >  > In theory, it really does not make sense to obtain performance
> >  > @@ -241,7 +241,7 @@ As noted in \cref{sec:defer:RCU Fundamentals}
> >  > an important component
> >  > of RCU is a way of waiting for RCU readers to finish.
> >  > One of
> >  > -RCU's great strength is that it allows you to wait for each of
> >  > +RCU's great strengths is that it allows you to wait for each of
> >  > thousands of different things to finish without having to explicitly
> >  > track each and every one of them, and without incurring
> >  > the performance degradation, scalability limitations, complex deadlock
> >  > diff --git a/defer/whichtochoose.tex b/defer/whichtochoose.tex
> >  > index a152b028..a11de412 100644
> >  > --- a/defer/whichtochoose.tex
> >  > +++ b/defer/whichtochoose.tex
> >  > @@ -102,8 +102,8 @@ and that there be sufficient pointers for each CPU or thread to
> >  > track all the objects being referenced at any given time.
> >  > Given that most hazard-pointer-based traversals require only a few
> >  > hazard pointers, this is not normally a problem in practice.
> >  > -Of course, sequence locks provides no pointer-traversal protection,
> >  > -which is why it is normally used on static data.
> >  > +Of course, sequence locks provide no pointer-traversal protection,
> >  > +which is why they are normally used on static data.
> >  > 
> >  > \QuickQuiz{
> >  > Why can't users dynamically allocate the hazard pointers as they
> >  > @@ -124,7 +124,7 @@ RCU readers must therefore be relatively short in order to avoid running
> >  > the system out of memory, with special-purpose implementations such
> >  > as SRCU, Tasks RCU, and Tasks Trace RCU being exceptions to this rule.
> >  > Again, sequence locks provide no pointer-traversal protection,
> >  > -which is why it is normally used on static data.
> >  > +which is why they are normally used on static data.
> >  > 
> >  > The ``Need for Traversal Retries'' row tells whether a new reference to
> >  > a given object may be acquired unconditionally, as it can with RCU, or
> >  > @@ -319,7 +319,7 @@ Hazard pointers incur the overhead of a \IX{memory barrier}
> >  > for each data element
> >  > traversed, and sequence locks incur the overhead of a pair of memory barriers
> >  > for each attempt to execute the critical section.
> >  > -The overhead of RCU implementations vary from nothing to that of a pair of
> >  > +The overhead of RCU implementations varies from nothing to that of a pair of
> >  > memory barriers for each read-side critical section, thus providing RCU
> >  > with the best performance, particularly for read-side critical sections
> >  > that traverse many data elements.
> >  > @@ -622,7 +622,7 @@ Stjepan Glavina merged an epoch-based RCU implementation into the
> >  > \co{crossbeam} set of concurrency-support ``crates'' for the Rust
> >  > language~\cite{StjepanGlavina2018RustRCU}.
> >  > 
> >  > -Jason Donenfeld produced an RCU implementations as part of his port of
> >  > +Jason Donenfeld produced an RCU implementation as part of his port of
> >  > WireGuard to Windows~NT kernel~\cite{JasonDonenfeld2021:WindowsNTwireguardRCU}.
> >  > 
> >  > Finally, any garbage-collected concurrent language (not just Go!\@) gets
> >  > -- 
> >  > 2.25.1
> >  >
> >
>

Re: [PATCH] defer: Fix grammar issues across Chapter 9 text

[Akira Yokosawa]

Hi,

Let me chime in.

On Fri, 27 Feb 2026 02:34:43 +0000, Kunwu Chan wrote:
[...]

> Hi Paul,
> 
> Sounds good. I went through the current PDF and gathered the occurrences 
> of "hinted at/on" that I could find. Here is the list for review:
> 
> Using PDF file: perfbook.2025.12.18a.pdf.
> 
> 1) PDF location:
>    p.98 (PDF page 110/686), Chapter 6 (Beyond Partitioning)
>    Source location: SMPdesign/beyond.tex (line 14)
> 
>    “This chapter has discussed how data partitioning can be used to
>    design simple linearly scalable parallel programs.
>    \Cref{sec:SMPdesign:Data Ownership} hinted at the possibilities of
>    data replication, which will be used to great effect in
>    \cref{sec:defer:Read-Copy Update (RCU)}.”
> 
> 2) PDF location:
>    p.142 (PDF page 154/686), Chapter 9.4 (Sequence Locks)
>    Source location: defer/seqlock.tex (lines 411–416)
> 
>    “As hinted on
>    \cpageref{sec:defer:Mysteries sequence locking},
>    both the read-side and write-side critical sections of a sequence
>    lock can be thought of as transactions, and sequence locking
>    therefore can be thought of as a limited form of transactional
>    memory, which will be discussed in
>    \cref{sec:future:Transactional Memory}.”
> 
> 3) PDF location:
>    p.155 (PDF page 167/686), Chapter 9.5 (RCU)
>    Source location: defer/rcufundamental.tex (lines 559–563)
> 
>    “In such cases, RCU readers can be considered to be fully ordered with
>    updaters, despite the fact that these readers might be executing the
>    exact same sequence of machine instructions that would be executed by
>    a single-threaded program, as hinted on
>    \cpageref{sec:defer:Mysteries RCU}.”
> 
> 4) PDF location:
>    p.184 (PDF page 196/686), Chapter 9.5.4.12 area
>    Source location: defer/rcuusage.tex (lines 2052–2054)
> 
>    “And so it is that RCU's use cases are conceptually more complex than
>    is RCU itself, as hinted on
>    \cpageref{sec:defer:Mysteries RCU Use Cases}.”
> 
> 5) PDF location:
>    p.533 (PDF page 545/686), Quick Quiz answers area
>    Source location: defer/rcuintro.tex (lines 141–145)
> 
>    “As hinted at in
>    \cref{sec:cpu:Hardware Optimizations,sec:cpu:Hardware Free Lunch?},
>    speed-of-light delays mean that a computer's data is always stale
>    compared to whatever external reality that data is intended to model.”
> 
> Please let me know which ones you’d prefer to keep as-is and 
> which should be adjusted, and I’ll prepare a patch accordingly.

Not a native speaker of English, but I don't see any need of changing them.

From 1)

  Section XXX hinted at the possibilities of data replication, ...

From 2), 3), and 4)
  
  As/as hinted on page YYY ...

From 5)

  As hinted at in Section ZZZ, ...

All of them sound pretty natural to me.

You might be missing the implication of "page XXX", which can mean
physical page in a book.  Saying "on page XXX" is quite natural.
OTOH, when you see "Section XXX hinted at <some ideas>", you should
consider "hint at" works as a synonym of "indicate" as a verb.

Hope this helps.

Thanks, Akira

> 
> 
> Thanx, Kunwu

Re: [PATCH] defer: Fix grammar issues across Chapter 9 text

[Paul E. McKenney]

On Fri, Feb 27, 2026 at 12:48:45PM +0900, Akira Yokosawa wrote:
> Hi,
> 
> Let me chime in.

Thank you both for digging into this!

I am with Akira on these.  Responding to each inline...

> On Fri, 27 Feb 2026 02:34:43 +0000, Kunwu Chan wrote:
> [...]
> 
> > Hi Paul,
> > 
> > Sounds good. I went through the current PDF and gathered the occurrences 
> > of "hinted at/on" that I could find. Here is the list for review:
> > 
> > Using PDF file: perfbook.2025.12.18a.pdf.
> > 
> > 1) PDF location:
> >    p.98 (PDF page 110/686), Chapter 6 (Beyond Partitioning)
> >    Source location: SMPdesign/beyond.tex (line 14)
> > 
> >    “This chapter has discussed how data partitioning can be used to
> >    design simple linearly scalable parallel programs.
> >    \Cref{sec:SMPdesign:Data Ownership} hinted at the possibilities of
> >    data replication, which will be used to great effect in
> >    \cref{sec:defer:Read-Copy Update (RCU)}.”

Here we are referencing a section, so we say "in Section ...".

> > 2) PDF location:
> >    p.142 (PDF page 154/686), Chapter 9.4 (Sequence Locks)
> >    Source location: defer/seqlock.tex (lines 411–416)
> > 
> >    “As hinted on
> >    \cpageref{sec:defer:Mysteries sequence locking},
> >    both the read-side and write-side critical sections of a sequence
> >    lock can be thought of as transactions, and sequence locking
> >    therefore can be thought of as a limited form of transactional
> >    memory, which will be discussed in
> >    \cref{sec:future:Transactional Memory}.”

And here as well.

> > 3) PDF location:
> >    p.155 (PDF page 167/686), Chapter 9.5 (RCU)
> >    Source location: defer/rcufundamental.tex (lines 559–563)
> > 
> >    “In such cases, RCU readers can be considered to be fully ordered with
> >    updaters, despite the fact that these readers might be executing the
> >    exact same sequence of machine instructions that would be executed by
> >    a single-threaded program, as hinted on
> >    \cpageref{sec:defer:Mysteries RCU}.”

But the English language being what it is, we say "on page ...".
The rational is that when you read a physical dead-tree book, the page is
laid out flat, with the ink you are reading being physically on the page.
As opposed to inside of it or something.

> > 4) PDF location:
> >    p.184 (PDF page 196/686), Chapter 9.5.4.12 area
> >    Source location: defer/rcuusage.tex (lines 2052–2054)
> > 
> >    “And so it is that RCU's use cases are conceptually more complex than
> >    is RCU itself, as hinted on
> >    \cpageref{sec:defer:Mysteries RCU Use Cases}.”

Again "on page ...".

> > 5) PDF location:
> >    p.533 (PDF page 545/686), Quick Quiz answers area
> >    Source location: defer/rcuintro.tex (lines 141–145)
> > 
> >    “As hinted at in
> >    \cref{sec:cpu:Hardware Optimizations,sec:cpu:Hardware Free Lunch?},
> >    speed-of-light delays mean that a computer's data is always stale
> >    compared to whatever external reality that data is intended to model.”

And again "in Section ...".

One way of thinking of this is that sections are usually multiple pages.
If you held in your hand the pages making up a section, the writing
would be in (not on) the stack of pages.

> > Please let me know which ones you’d prefer to keep as-is and 
> > which should be adjusted, and I’ll prepare a patch accordingly.
> 
> Not a native speaker of English, but I don't see any need of changing them.
> 
> >From 1)
> 
>   Section XXX hinted at the possibilities of data replication, ...
> 
> >From 2), 3), and 4)
>   
>   As/as hinted on page YYY ...
> 
> >From 5)
> 
>   As hinted at in Section ZZZ, ...
> 
> All of them sound pretty natural to me.
> 
> You might be missing the implication of "page XXX", which can mean
> physical page in a book.  Saying "on page XXX" is quite natural.
> OTOH, when you see "Section XXX hinted at <some ideas>", you should
> consider "hint at" works as a synonym of "indicate" as a verb.

I suspect that both Chinese and Japanese make different choices, but I
don't know enough about either to say.  Google Translate seems to treat
pages and sections the same for Chinese ("在第3页" and "在第2部分"
but Arabic numerals?) and for Japanese ("3ページにあります" and
"セクション2にあります" and also Arabic numerals?).  On the
other hand, I trust Google Translate only up to a point.  So you guys
tell me!  ;-)

For whatever it is worth, French is similar to English, with "à la"
for pages and "dans la" for sections, where "la" is the feminine form of
the English word "the".  The in/on/with words are big bags of meanings,
so French "à" can be English "on", but the meanings do not coincide
precisely, for example, "à" sometimes translates instead to English
"from".  However, French "dans" almost always translates to English "in".

I took four years of French in high school, mais cela signifie en
américain «Je ne parle pas français» ("but that is American for
'I don't speak French'").  ;-)

And you know the old joke:  English is what you get when Germans attempt
to speak French.

							Thanx, Paul

> Hope this helps.
> 
> Thanks, Akira
> 
> > 
> > 
> > Thanx, Kunwu

Re: [PATCH] defer: Fix grammar issues across Chapter 9 text

[Kunwu Chan]

February 28, 2026 at 3:13 AM, "Paul E. McKenney" <paulmck@kernel.org mailto:paulmck@kernel.org?to=%22Paul%20E.%20McKenney%22%20%3Cpaulmck%40kernel.org%3E > wrote:


> 
> On Fri, Feb 27, 2026 at 12:48:45PM +0900, Akira Yokosawa wrote:
> 
> > 
> > Hi,
> >  
> >  Let me chime in.
> > 
> Thank you both for digging into this!
> 
> I am with Akira on these. Responding to each inline...
> 
Thanks for the clear explanation — very helpful, appreciate it.

> > 
> > On Fri, 27 Feb 2026 02:34:43 +0000, Kunwu Chan wrote:
> >  [...]
> >  
> >  Hi Paul,
> >  
> >  Sounds good. I went through the current PDF and gathered the occurrences 
> >  of "hinted at/on" that I could find. Here is the list for review:
> >  
> >  Using PDF file: perfbook.2025.12.18a.pdf.
> >  
> >  1) PDF location:
> >  p.98 (PDF page 110/686), Chapter 6 (Beyond Partitioning)
> >  Source location: SMPdesign/beyond.tex (line 14)
> >  
> >  “This chapter has discussed how data partitioning can be used to
> >  design simple linearly scalable parallel programs.
> >  \Cref{sec:SMPdesign:Data Ownership} hinted at the possibilities of
> >  data replication, which will be used to great effect in
> >  \cref{sec:defer:Read-Copy Update (RCU)}.”
> > 
> Here we are referencing a section, so we say "in Section ...".
> 
Thanks.
> > 
> > 2) PDF location:
> >  p.142 (PDF page 154/686), Chapter 9.4 (Sequence Locks)
> >  Source location: defer/seqlock.tex (lines 411–416)
> >  
> >  “As hinted on
> >  \cpageref{sec:defer:Mysteries sequence locking},
> >  both the read-side and write-side critical sections of a sequence
> >  lock can be thought of as transactions, and sequence locking
> >  therefore can be thought of as a limited form of transactional
> >  memory, which will be discussed in
> >  \cref{sec:future:Transactional Memory}.”
> > 
> And here as well.
> 
> > 
> > 3) PDF location:
> >  p.155 (PDF page 167/686), Chapter 9.5 (RCU)
> >  Source location: defer/rcufundamental.tex (lines 559–563)
> >  
> >  “In such cases, RCU readers can be considered to be fully ordered with
> >  updaters, despite the fact that these readers might be executing the
> >  exact same sequence of machine instructions that would be executed by
> >  a single-threaded program, as hinted on
> >  \cpageref{sec:defer:Mysteries RCU}.”
> > 
> But the English language being what it is, we say "on page ...".
> The rational is that when you read a physical dead-tree book, the page is
> laid out flat, with the ink you are reading being physically on the page.
> As opposed to inside of it or something.
> 
Thanks — the "ink physically on the page" image really helped. 
Much easier to grasp. :-)

> > 
> > 4) PDF location:
> >  p.184 (PDF page 196/686), Chapter 9.5.4.12 area
> >  Source location: defer/rcuusage.tex (lines 2052–2054)
> >  
> >  “And so it is that RCU's use cases are conceptually more complex than
> >  is RCU itself, as hinted on
> >  \cpageref{sec:defer:Mysteries RCU Use Cases}.”
> > 
> Again "on page ...".
> 
> > 
> > 5) PDF location:
> >  p.533 (PDF page 545/686), Quick Quiz answers area
> >  Source location: defer/rcuintro.tex (lines 141–145)
> >  
> >  “As hinted at in
> >  \cref{sec:cpu:Hardware Optimizations,sec:cpu:Hardware Free Lunch?},
> >  speed-of-light delays mean that a computer's data is always stale
> >  compared to whatever external reality that data is intended to model.”
> > 
> And again "in Section ...".
> 
> One way of thinking of this is that sections are usually multiple pages.
> If you held in your hand the pages making up a section, the writing
> would be in (not on) the stack of pages.
> 
Thanks — that “stack of pages” picture makes it very clear.

> > 
> > Please let me know which ones you’d prefer to keep as-is and 
> >  which should be adjusted, and I’ll prepare a patch accordingly.
> >  
> >  Not a native speaker of English, but I don't see any need of changing them.
> >  
> > From 1)
> >  
> >  Section XXX hinted at the possibilities of data replication, ...
> >  
> > From 2), 3), and 4)
> >  
> >  As/as hinted on page YYY ...
> >  
> > From 5)
> >  
> >  As hinted at in Section ZZZ, ...
> >  
> >  All of them sound pretty natural to me.
> >  
> >  You might be missing the implication of "page XXX", which can mean
> >  physical page in a book. Saying "on page XXX" is quite natural.
> >  OTOH, when you see "Section XXX hinted at <some ideas>", you should
> >  consider "hint at" works as a synonym of "indicate" as a verb.
> > 
> I suspect that both Chinese and Japanese make different choices, but I
> don't know enough about either to say. Google Translate seems to treat
> pages and sections the same for Chinese ("在第3页" and "在第2部分"
> but Arabic numerals?) and for Japanese ("3ページにあります" and
> "セクション2にあります" and also Arabic numerals?). On the
> other hand, I trust Google Translate only up to a point. So you guys
> tell me! ;-)
> 
> For whatever it is worth, French is similar to English, with "à la"
> for pages and "dans la" for sections, where "la" is the feminine form of
> the English word "the". The in/on/with words are big bags of meanings,
> so French "à" can be English "on", but the meanings do not coincide
> precisely, for example, "à" sometimes translates instead to English
> "from". However, French "dans" almost always translates to English "in".
> 
> I took four years of French in high school, mais cela signifie en
> américain «Je ne parle pas français» ("but that is American for
> 'I don't speak French'"). ;-)
> 
> And you know the old joke: English is what you get when Germans attempt
> to speak French.
> 
Thanks for the explanation — very helpful.
The language notes (and the joke!) were fun too. 
Learned something new there. ;-)

Thanx, Kunwu

>  Thanx, Paul
> 
> > 
> > Hope this helps.
> >  
> >  Thanks, Akira
> >  
> >  
> >  
> >  Thanx, Kunwu
> >
>