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

["Kunwu Chan" <kunwu.chan@linux.dev>]

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
> >  >
> >
>