February 26, 2026 at 9:02 AM, "Paul E. McKenney" <[email protected] mailto:[email protected]?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 <[email protected]> > > > 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 > > >
