public inbox for perfbook@vger.kernel.org
 help / color / mirror / Atom feed
From: Kunwu Chan <kunwu.chan@linux.dev>
To: perfbook@vger.kernel.org
Cc: paulmck@kernel.org, Kunwu Chan <kunwu.chan@linux.dev>
Subject: [PATCH] defer: Fix typos across Chapter 9
Date: Mon, 16 Feb 2026 12:43:09 +0800	[thread overview]
Message-ID: <20260216044309.2207651-1-kunwu.chan@linux.dev> (raw)

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

diff --git a/defer/rcu.tex b/defer/rcu.tex
index c54da410..13078687 100644
--- a/defer/rcu.tex
+++ b/defer/rcu.tex
@@ -66,7 +66,7 @@ applied to virtually any data structure''.
 On the other hand, making good use of RCU often requires that you think
 differently about concurrency in general and about your use case in
 particular.
-Much of the remainder of this section therofore provides a guide to
+Much of the remainder of this section therefore provides a guide to
 mapping use cases onto RCU.
 
 \QuickQuiz{
diff --git a/defer/rcuapi.tex b/defer/rcuapi.tex
index 54c94233..9fa11626 100644
--- a/defer/rcuapi.tex
+++ b/defer/rcuapi.tex
@@ -135,7 +135,7 @@ and by
 which shows the publish-subscribe portions of the
 API~\cite{PaulEMcKenney2024RCUAPI}.\footnote{
 	This citation covers v6.10 and later.
-	Documetation for earlier versions of the Linux-kernel RCU API may
+	Documentation for earlier versions of the Linux-kernel RCU API may
 	be found elsewhere~\cite{PaulEMcKenney2008WhatIsRCUAPI,PaulEMcKenney2014RCUAPI,PaulEMcKenney2019RCUAPI}.}
 
 \begin{sidewaystable*}[tbp]
@@ -597,7 +597,7 @@ However, there are situations where this ease of use gets in the way,
 for example, when a cache of RCU-protected objects might be subject
 to reuse during the grace period that otherwise would have allowed them
 to be freed.
-Although this can be handed through careful use of flags that interact
+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()}
 invocations.
diff --git a/defer/rcufundamental.tex b/defer/rcufundamental.tex
index 0efdf406..c3bcc4f0 100644
--- a/defer/rcufundamental.tex
+++ b/defer/rcufundamental.tex
@@ -484,7 +484,7 @@ In contrast, in
 \cref{fig:defer:Multiple RCU Data-Structure Versions}
 the reader sees a version that never actually existed!
 
-One way to resolve this strange situation is via weaker semanitics.
+One way to resolve this strange situation is via weaker semantics.
 A reader traversal must encounter any data item that was present
 during the full traversal (B, C, and~D), and might or might not
 encounter data items that were present for only part of the
diff --git a/defer/rcuintro.tex b/defer/rcuintro.tex
index d3a55a47..48de32e2 100644
--- a/defer/rcuintro.tex
+++ b/defer/rcuintro.tex
@@ -145,7 +145,7 @@ the state, as indicated by the ``2~Versions'' in the figure.
 	to model.
 
 	Real-world algorithms therefore absolutely must tolerate
-	inconsistancies between external reality and the in-computer
+	inconsistencies between external reality and the in-computer
 	data reflecting that reality.
 	Many of those algorithms are also able to tolerate some degree
 	of inconsistency within the in-computer data.
diff --git a/defer/rcurelated.tex b/defer/rcurelated.tex
index 8846825f..cf4b7b49 100644
--- a/defer/rcurelated.tex
+++ b/defer/rcurelated.tex
@@ -391,7 +391,7 @@ sleepable RCU (SRCU)~\cite{PaulEMcKenney2006c}.
 Finally, \ppl{Michalis}{Kokologiannakis} and \ppl{Konstantinos}{Sagonas}
 (National Technical University of
 Athens)~\cite{MichalisKokologiannakis2017NidhuggRCU,MichalisKokologiannakis2019RCUstatelessModelCheck}
-used the Nighugg tool~\cite{CarlLeonardsson2014Nidhugg}
+used the Nidhugg tool~\cite{CarlLeonardsson2014Nidhugg}
 to produce a mechanical proof of correctness of a somewhat larger
 portion of Linux-kernel Tree RCU\@.
 
diff --git a/defer/rcuusage.tex b/defer/rcuusage.tex
index 6225c672..63e12a40 100644
--- a/defer/rcuusage.tex
+++ b/defer/rcuusage.tex
@@ -226,7 +226,7 @@ that of the ideal synchronization-free workload.
 \end{figure*}
 
 Although Pre-BSD routing is an excellent RCU use case, it is worthwhile
-looking at the relationships betweeen the wider spectrum of use cases
+looking at the relationships between the wider spectrum of use cases
 shown in
 \cref{fig:defer:Relationships Between RCU Use Cases}.
 This task is taken up by the following sections.
@@ -520,7 +520,7 @@ run concurrently with \co{do_maint()} to complete, and finally
 	function's load from \co{be_careful} and any memory loads
 	executed by the \co{cco_quickly()} function.
 	Because there is no ordering, without that second call to
-	\co{syncrhonize_rcu()}, memory ordering could cause loads
+	\co{synchronize_rcu()}, memory ordering could cause loads
 	in \co{cco_quickly()} to overlap with stores by \co{do_maint()}.
 
 	Another alternative would be to compensate for the removal of
@@ -852,7 +852,7 @@ and \clnref{ret_0:b} indicates failure to delete the specified key.
 \QuickQuizE{
 	The RCU-based algorithm shown in
 	\cref{lst:defer:Existence Guarantees Enable Per-Element Locking}
-	locks very similar to that in
+	looks very similar to that in
 	\cref{lst:locking:Per-Element Locking With Lock-Based Existence Guarantees},
 	so why should the RCU-based approach be any better?
 }\QuickQuizAnswerE{
@@ -1057,7 +1057,7 @@ which was generated on a 448-CPU 2.10\,GHz Intel x86 system.
 
 	Nor was this a theoretical problem:
 	A failure actually manifested in 2019.
-	\ppl{Herbert}{Xu} tracked down this failure down and
+	\ppl{Herbert}{Xu} tracked down this failure and
 	\ppl{Linus}{Torvalds}
 	therefore queued a commit to upgrade \co{rcu_read_lock()} and
 	\co{rcu_read_unlock()} to unconditionally include a call to
@@ -1356,7 +1356,7 @@ analysis~\cite[Figures 3 and 5]{VishakhaRamani2023LockBasedLocklessFresh}.
 	at the time that it arrives, and extremely stale in the case
 	of astronomical data.
 	The finite speed of light also places a sharp limit on the
-	consistency of data arriving from different sources of via
+	consistency of data arriving from different sources or via
 	different paths.
 
 	You might as well face the fact that the laws of physics
diff --git a/defer/updates.tex b/defer/updates.tex
index 92e1fe93..7536e172 100644
--- a/defer/updates.tex
+++ b/defer/updates.tex
@@ -21,7 +21,7 @@ scalability for writers, namely the counting algorithms surveyed in
 These algorithms featured partially partitioned data structures so
 that updates can operate locally, while the more-expensive reads
 must sum across the entire data structure.
-Silas Boyd-Wickhizer has generalized this notion to produce
+Silas Boyd-Wickizer has generalized this notion to produce
 OpLog, which he has applied to
 Linux-kernel pathname lookup, VM reverse mappings, and the \co{stat()} system
 call~\cite{SilasBoydWickizerPhD}.
diff --git a/defer/whichtochoose.tex b/defer/whichtochoose.tex
index dfa19426..775da269 100644
--- a/defer/whichtochoose.tex
+++ b/defer/whichtochoose.tex
@@ -397,7 +397,7 @@ instructions.
 	This limits lock contention and prevents both preemption and
 	interrupts from delaying execution while those locks are held,
 	in turn providing excellent forward
-	progrees~\cite{BjoernBrandenburgPhD,DanielBristot2019RTtrace,Hillier86,DipankarSarma2004OLSscalability}.
+	progress~\cite{BjoernBrandenburgPhD,DanielBristot2019RTtrace,Hillier86,DipankarSarma2004OLSscalability}.
 
 	In short, formalisms such as wait-free synchronization have their
 	place, but the really important thing is to figure out what your
-- 
2.25.1


             reply	other threads:[~2026-02-16  4:44 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-02-16  4:43 Kunwu Chan [this message]
2026-02-16 20:06 ` [PATCH] defer: Fix typos across Chapter 9 Paul E. McKenney

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260216044309.2207651-1-kunwu.chan@linux.dev \
    --to=kunwu.chan@linux.dev \
    --cc=paulmck@kernel.org \
    --cc=perfbook@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox