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

February 26, 2026 at 9:02 AM, "Paul E. McKenney" <[email protected] mail=
to:[email protected]?to=3D%22Paul%20E.%20McKenney%22%20%3Cpaulmck%40kern=
el.org%3E > wrote:


>=20
>=20On Wed, Feb 25, 2026 at 08:44:24PM +0800, Kunwu Chan wrote:
>=20
>=20>=20
>=20> Fix subject-verb agreement, singular/plural forms, pronoun agreemen=
t,
> >  and countability in Chapter 9 prose.
> >=20=20
>=20>  These wording-only edits improve readability without changing
> >  technical meaning.
> >=20=20
>=20>  Signed-off-by: Kunwu Chan <[email protected]>
> >=20
>=20Again, good eyes and thank you! I applied all three, with the excepti=
on of=20
>=20this hunk:
>=20
>=20---------------------------------------------------------------------=
---
>=20
>=20diff --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}
>=20
>=20---------------------------------------------------------------------=
---
>=20
>=20This 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?
>=20
>=20 Thanx, Paul
>=20
Makes=20sense =E2=80=94 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 "hint=
ed on".
I can send a small follow-up patch to make them consistent if that sounds=
 good.

Thanx, Kunwu

> >=20
>=20> ---
> >  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(-)
> >=20=20
>=20>  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 packe=
t
> >  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 inter=
act
> >  with the RCU callback queued by \co{call_rcu()}, this can be inconve=
nient
> >  -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_r=
cu()}
> >  invocations.
> >=20=20
>=20>  In these cases, RCU's polled grace-period primitives can be helpfu=
l.
> >  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.
> >=20=20
>=20>  -The common use of RCU to protect linked data structure is compris=
ed
> >  +The common use of RCU to protect linked data structures is comprise=
d
> >  of three fundamental mechanisms, the first being used for insertion,
> >  the second being used for deletion, and the third being used to allo=
w
> >  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!
> >=20=20
>=20>  - 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 deadlo=
ck
> >  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 C=
PU 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.
> >=20=20
>=20>  \QuickQuiz{
> >  Why can't users dynamically allocate the hazard pointers as they
> >  @@ -124,7 +124,7 @@ RCU readers must therefore be relatively short i=
n 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 rul=
e.
> >  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.
> >=20=20
>=20>  The ``Need for Traversal Retries'' row tells whether a new referen=
ce 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{memo=
ry 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 secti=
ons
> >  that traverse many data elements.
> >  @@ -622,7 +622,7 @@ Stjepan Glavina merged an epoch-based RCU implem=
entation into the
> >  \co{crossbeam} set of concurrency-support ``crates'' for the Rust
> >  language~\cite{StjepanGlavina2018RustRCU}.
> >=20=20
>=20>  -Jason Donenfeld produced an RCU implementations as part of his po=
rt of
> >  +Jason Donenfeld produced an RCU implementation as part of his port =
of
> >  WireGuard to Windows~NT kernel~\cite{JasonDonenfeld2021:WindowsNTwir=
eguardRCU}.
> >=20=20
>=20>  Finally, any garbage-collected concurrent language (not just Go!\@=
) gets
> >  --=20
>=20>  2.25.1
> >
>