* [PATCH 1/3 -perfbook] bib/hw: Improve looks of WilliamGWong2019CCIX-CXL's title
@ 2021-03-20 15:16 Akira Yokosawa
2021-03-20 15:23 ` [PATCH 2/3 -perfbook] together/refcnt: Adjust tense with 'have released' Akira Yokosawa
2021-03-20 15:24 ` [PATCH 3/3 -perfbook] debugging: Fix typo Akira Yokosawa
0 siblings, 2 replies; 12+ messages in thread
From: Akira Yokosawa @ 2021-03-20 15:16 UTC (permalink / raw
To: Paul E. McKenney; +Cc: perfbook, Akira Yokosawa
Also avoid the UTF-8 encoded symbol of "…".
\ldots looks close enough to the title of the web page.
Signed-off-by: Akira Yokosawa <akiyks@gmail.com>
---
bib/hw.bib | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/bib/hw.bib b/bib/hw.bib
index 2ece29d6..ccb35e94 100644
--- a/bib/hw.bib
+++ b/bib/hw.bib
@@ -1025,7 +1025,7 @@ Luis Stevens and Anoop Gupta and John Hennessy",
@unpublished{WilliamGWong2019CCIX-CXL,
Author="William G. Wong",
- Title="VHS or Betamax…CCIX or CXL…So Many Choices",
+ Title="{VHS} or {Betamax} \ldots\ {CCIX} or {CXL} \ldots\ So Many Choices",
month="March",
day="14",
year="2019",
--
2.17.1
^ permalink raw reply related [flat|nested] 12+ messages in thread
* [PATCH 2/3 -perfbook] together/refcnt: Adjust tense with 'have released'
2021-03-20 15:16 [PATCH 1/3 -perfbook] bib/hw: Improve looks of WilliamGWong2019CCIX-CXL's title Akira Yokosawa
@ 2021-03-20 15:23 ` Akira Yokosawa
2021-03-20 19:03 ` Paul E. McKenney
2021-03-20 15:24 ` [PATCH 3/3 -perfbook] debugging: Fix typo Akira Yokosawa
1 sibling, 1 reply; 12+ messages in thread
From: Akira Yokosawa @ 2021-03-20 15:23 UTC (permalink / raw
To: Paul E. McKenney; +Cc: perfbook, Akira Yokosawa
Signed-off-by: Akira Yokosawa <akiyks@gmail.com>
---
Paul,
This is in your recent update.
The former part of "or" says "both CPUs have released ...", so the
latter part should say "(both CPUs have) exited ...", I suppose.
"or have exited" might be the right fix, but it sounds redundant
to me. Up to you!
Thanks, Akira
--
together/refcnt.tex | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/together/refcnt.tex b/together/refcnt.tex
index 829af167..599ae5f0 100644
--- a/together/refcnt.tex
+++ b/together/refcnt.tex
@@ -257,7 +257,7 @@ and any needed memory barriers or disabling of compiler optimizations
will be provided by the hazard-pointers or RCU infrastructure.
Therefore, if two CPUs release the final two references concurrently, the
actual cleanup will be deferred until both CPUs have released their hazard
-pointers or exits their RCU read-side critical sections, respectively.
+pointers or exited their RCU read-side critical sections, respectively.
\QuickQuiz{
Why isn't it necessary to guard against cases where one CPU
--
2.17.1
^ permalink raw reply related [flat|nested] 12+ messages in thread
* [PATCH 3/3 -perfbook] debugging: Fix typo
2021-03-20 15:16 [PATCH 1/3 -perfbook] bib/hw: Improve looks of WilliamGWong2019CCIX-CXL's title Akira Yokosawa
2021-03-20 15:23 ` [PATCH 2/3 -perfbook] together/refcnt: Adjust tense with 'have released' Akira Yokosawa
@ 2021-03-20 15:24 ` Akira Yokosawa
2021-03-20 15:50 ` Akira Yokosawa
1 sibling, 1 reply; 12+ messages in thread
From: Akira Yokosawa @ 2021-03-20 15:24 UTC (permalink / raw
To: Paul E. McKenney; +Cc: perfbook, Akira Yokosawa
Signed-off-by: Akira Yokosawa <akiyks@gmail.com>
---
debugging/debugging.tex | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/debugging/debugging.tex b/debugging/debugging.tex
index fd52d9e7..3f697f58 100644
--- a/debugging/debugging.tex
+++ b/debugging/debugging.tex
@@ -755,7 +755,7 @@ access to data.
The Kernel Concurrency Sanitizer (KCSAN)~\cite{JonathanCorbet2019KCSAN}
uses existing markings such as \co{READ_ONCE()} and \co{WRITE_ONCE()}
to determine which concurrent accesses deserve warning messages.
-KCSAN has a significant false-positive rate, especially in from the
+KCSAN has a significant false-positive rate, especially from the
viewpoint of developers thinking in terms of C as assembly language
with additional syntax.
KCSAN therefore provides a \co{data_race()} construct to forgive
--
2.17.1
^ permalink raw reply related [flat|nested] 12+ messages in thread
* Re: [PATCH 3/3 -perfbook] debugging: Fix typo
2021-03-20 15:24 ` [PATCH 3/3 -perfbook] debugging: Fix typo Akira Yokosawa
@ 2021-03-20 15:50 ` Akira Yokosawa
2021-03-20 19:23 ` Paul E. McKenney
0 siblings, 1 reply; 12+ messages in thread
From: Akira Yokosawa @ 2021-03-20 15:50 UTC (permalink / raw
To: Paul E. McKenney; +Cc: perfbook, Akira Yokosawa
On Sun, 21 Mar 2021 00:24:46 +0900, Akira Yokosawa wrote:
> Signed-off-by: Akira Yokosawa <akiyks@gmail.com>
> ---
> debugging/debugging.tex | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/debugging/debugging.tex b/debugging/debugging.tex
> index fd52d9e7..3f697f58 100644
> --- a/debugging/debugging.tex
> +++ b/debugging/debugging.tex
> @@ -755,7 +755,7 @@ access to data.
> The Kernel Concurrency Sanitizer (KCSAN)~\cite{JonathanCorbet2019KCSAN}
> uses existing markings such as \co{READ_ONCE()} and \co{WRITE_ONCE()}
> to determine which concurrent accesses deserve warning messages.
> -KCSAN has a significant false-positive rate, especially in from the
> +KCSAN has a significant false-positive rate, especially from the
> viewpoint of developers thinking in terms of C as assembly language
> with additional syntax.
> KCSAN therefore provides a \co{data_race()} construct to forgive
>
Paul,
I caught this one while searching the usage of "data race" in perfbook.
I thought "data race" also deserves an entry in Glossaries, especially
because our use of "data race" is heavily related to compiler
optimizations and somewhat stricter than the common definition
found on the web.
The first of data race in Section 4.2.2 (just before QQ4.8) does
not (explicitly) talk about optimizations.
Would it be possible for you to come up with some concise definition
of data race which will fit as an entry in the Glossaries?
Thanks, Akira
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH 2/3 -perfbook] together/refcnt: Adjust tense with 'have released'
2021-03-20 15:23 ` [PATCH 2/3 -perfbook] together/refcnt: Adjust tense with 'have released' Akira Yokosawa
@ 2021-03-20 19:03 ` Paul E. McKenney
0 siblings, 0 replies; 12+ messages in thread
From: Paul E. McKenney @ 2021-03-20 19:03 UTC (permalink / raw
To: Akira Yokosawa; +Cc: perfbook
On Sun, Mar 21, 2021 at 12:23:13AM +0900, Akira Yokosawa wrote:
> Signed-off-by: Akira Yokosawa <akiyks@gmail.com>
> ---
> Paul,
>
> This is in your recent update.
> The former part of "or" says "both CPUs have released ...", so the
> latter part should say "(both CPUs have) exited ...", I suppose.
>
> "or have exited" might be the right fix, but it sounds redundant
> to me. Up to you!
In this case, what you have works fine. The reason that it works is
because there is only the four words "released their hazard pointers"
between "both CPUs have" and "exited their...". If there was instead
a long run of text instead of just four words, repeating the "both CPUs
have" would be a good way of helping the reader to make the connection
across that long run of text.
I took all three patches, all good catches! My eyes apparently are not
as young as they once were, so thank you very much!!!
Thanx, Paul
> Thanks, Akira
> --
> together/refcnt.tex | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/together/refcnt.tex b/together/refcnt.tex
> index 829af167..599ae5f0 100644
> --- a/together/refcnt.tex
> +++ b/together/refcnt.tex
> @@ -257,7 +257,7 @@ and any needed memory barriers or disabling of compiler optimizations
> will be provided by the hazard-pointers or RCU infrastructure.
> Therefore, if two CPUs release the final two references concurrently, the
> actual cleanup will be deferred until both CPUs have released their hazard
> -pointers or exits their RCU read-side critical sections, respectively.
> +pointers or exited their RCU read-side critical sections, respectively.
>
> \QuickQuiz{
> Why isn't it necessary to guard against cases where one CPU
> --
> 2.17.1
>
>
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH 3/3 -perfbook] debugging: Fix typo
2021-03-20 15:50 ` Akira Yokosawa
@ 2021-03-20 19:23 ` Paul E. McKenney
2021-03-21 1:03 ` Akira Yokosawa
0 siblings, 1 reply; 12+ messages in thread
From: Paul E. McKenney @ 2021-03-20 19:23 UTC (permalink / raw
To: Akira Yokosawa; +Cc: perfbook
On Sun, Mar 21, 2021 at 12:50:43AM +0900, Akira Yokosawa wrote:
> On Sun, 21 Mar 2021 00:24:46 +0900, Akira Yokosawa wrote:
> > Signed-off-by: Akira Yokosawa <akiyks@gmail.com>
> > ---
> > debugging/debugging.tex | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/debugging/debugging.tex b/debugging/debugging.tex
> > index fd52d9e7..3f697f58 100644
> > --- a/debugging/debugging.tex
> > +++ b/debugging/debugging.tex
> > @@ -755,7 +755,7 @@ access to data.
> > The Kernel Concurrency Sanitizer (KCSAN)~\cite{JonathanCorbet2019KCSAN}
> > uses existing markings such as \co{READ_ONCE()} and \co{WRITE_ONCE()}
> > to determine which concurrent accesses deserve warning messages.
> > -KCSAN has a significant false-positive rate, especially in from the
> > +KCSAN has a significant false-positive rate, especially from the
> > viewpoint of developers thinking in terms of C as assembly language
> > with additional syntax.
> > KCSAN therefore provides a \co{data_race()} construct to forgive
> >
>
> Paul,
>
> I caught this one while searching the usage of "data race" in perfbook.
> I thought "data race" also deserves an entry in Glossaries, especially
> because our use of "data race" is heavily related to compiler
> optimizations and somewhat stricter than the common definition
> found on the web.
>
> The first of data race in Section 4.2.2 (just before QQ4.8) does
> not (explicitly) talk about optimizations.
>
> Would it be possible for you to come up with some concise definition
> of data race which will fit as an entry in the Glossaries?
How about like the following?
Thanx, Paul
------------------------------------------------------------------------
commit da6dcf306cf2eb05324c306bbed230cc543fc426
Author: Paul E. McKenney <paulmck@kernel.org>
Date: Sat Mar 20 12:21:07 2021 -0700
toolsoftrade,glossary: Explain data races
While in the area, make the cases of index entries consistent,
fixing my copy-pasta from the glossary entry.
Reported-by: Akira Yokosawa <akiyks@gmail.com>
Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
diff --git a/glossary.tex b/glossary.tex
index c6c9c62..e6aa612 100644
--- a/glossary.tex
+++ b/glossary.tex
@@ -38,13 +38,13 @@
is atomic, because other CPUs will see either the old value or
the new value, but are guaranteed not to see some mixed value
containing some pieces of the new and old values.
-\item[Atomic Read-Modify-Write Operation:]\index{Atomic Read-Modify-Write Operation}
+\item[Atomic Read-Modify-Write Operation:]\index{Atomic read-modify-write operation}
An atomic operation that both reads and writes memory is
considered an atomic read-modify-write operation, or atomic RMW
operation for short.
Although the value written usually depends on the value read,
\co{atomic_xchg()} is the exception that proves this rule.
-\item[Bounded Wait Free:]\index{Bounded Wait Free}
+\item[Bounded Wait Free:]\index{Bounded wait free}
A forward-progress guarantee in which every thread makes
progress within a specific finite period of time, the specific
time being the bound.
@@ -126,7 +126,7 @@
\item[Capacity Miss:]\index{Capacity miss}
A cache miss incurred because the corresponding CPU has recently
accessed more data than will fit into the cache.
-\item[Clash Free:]\index{Clash Free}
+\item[Clash Free:]\index{Clash free}
A forward-progress guarantee in which, in the absence of
contention, at least one thread makes progress within a finite
period of time.
@@ -170,7 +170,16 @@
increasing numbers of CPUs as the number of instances of
data grows.
Contrast with ``code locking''.
-\item[Deadlock Free:]\index{Deadlock Free}
+\item[Data Race:]\index{Data race}
+ A race condition in which several CPUs or threads access
+ a variable concurrently, and in which at least one of those
+ accesses is a store and at least one of those accesses
+ is unmarked.
+ It is important to note that while the presence of data races
+ often indicates the presence of bugs, the absence of data races
+ in no way implies the absence of bugs.
+ (See ``Marked access''.)
+\item[Deadlock Free:]\index{Deadlock free}
A forward-progress guarantee in which, in the absence of
failures, at least one thread makes progress within a finite
period of time.
@@ -226,7 +235,7 @@
Since RCU read-side critical sections by definition cannot
contain quiescent states, these two definitions are almost
always interchangeable.
-\item[Hazard Pointer:]\index{Hazard Pointer}
+\item[Hazard Pointer:]\index{Hazard pointer}
A scalable counterpart to a reference counter in which an
object's reference count is represented implicitly by a count
of the number of special hazard pointers referencing that object.
@@ -284,9 +293,21 @@
used so heavily that there is often a CPU waiting on it.
Reducing lock contention is often a concern when designing
parallel algorithms and when implementing parallel programs.
-\item[Lock Free:]\index{Lock Free}
+\item[Lock Free:]\index{Lock free}
A forward-progress guarantee in which at least one thread makes
progress within a finite period of time.
+\item[Marked Access:]\index{Marked access}
+ A source-code memory access that uses a special function or
+ macro, such as \co{READ_ONCE()}, \co{WRITE_ONCE()},
+ \co{atomic_inc()}, and so on, in order to protect that access
+ from compiler and/or hardware optimizations.
+ In contrast, an unmarked access simply mentions the name of
+ the object being accessed, so that in the following, line~2
+ is the unmarked equivalent of line~1:
+ \begin{VerbatimN}
+ WRITE_ONCE(a, READ_ONCE(b) + READ_ONCE(c));
+ a = b + c;
+ \end{VerbatimN}
\item[Memory:]\index{Memory}
From the viewpoint of memory models, the main memory,
caches, and store buffers in which values might be stored.
@@ -345,7 +366,7 @@
\item[NUMA Node:]\index{NUMA node}
A group of closely placed CPUs and associated memory within
a larger NUMA machines.
-\item[Obstruction Free:]\index{Obstruction Free}
+\item[Obstruction Free:]\index{Obstruction free}
A forward-progress guarantee in which, in the absence of
contention, every thread makes progress within a finite
period of time.
@@ -428,7 +449,7 @@
wait for the writer to release the lock.
A key concern for reader-writer locks is ``fairness'':
can an unending stream of readers starve a writer or vice versa.
-\item[Real Time:]\index{Real Time}
+\item[Real Time:]\index{Real time}
A situation in which getting the correct result is not sufficient,
but where this result must also be obtained within a given amount
of time.
@@ -437,7 +458,7 @@
additional resources.
For parallel computing, the additional resources are usually
additional CPUs.
-\item[Sequence Lock:]\index{Sequence Lock}
+\item[Sequence Lock:]\index{Sequence lock}
A reader-writer synchronization mechanism in which readers
retry their operations if a writer was present.
\item[Sequential Consistency:]\index{Sequential consistency}
@@ -445,7 +466,7 @@
in an order consistent with
a single global order, and where each CPU's memory references
appear to all CPUs to occur in program order.
-\item[Starvation Free:]\index{Starvation Free}
+\item[Starvation Free:]\index{Starvation free}
A forward-progress guarantee in which, in the absence of
failures, every thread makes progress within a finite
period of time.
@@ -483,7 +504,7 @@
they understand completely and are therefore comfortable teaching.
\item[Throughput:]\index{Throughput}
A performance metric featuring work items completed per unit time.
-\item[Transactional Lock Elision (TLE):]\index{Transactional Lock Elision (TLE)}
+\item[Transactional Lock Elision (TLE):]\index{Transactional lock elision (TLE)}
The use of transactional memory to emulate locking.
Synchronization is instead carried out by conflicting accesses
to the data to be protected by the lock.
@@ -503,7 +524,7 @@
In the 1960s through the 1980s, only supercomputers had vector
capabilities, but the advent of MMX in x86 CPUs and VMX in
PowerPC CPUs brought vector processing to the masses.
-\item[Wait Free:]\index{Wait Free}
+\item[Wait Free:]\index{Wait free}
A forward-progress guarantee in which every thread makes
progress within a finite period of time.
\item[Write Miss:]\index{Write miss}
diff --git a/toolsoftrade/toolsoftrade.tex b/toolsoftrade/toolsoftrade.tex
index 1f667e0..9e0838c 100644
--- a/toolsoftrade/toolsoftrade.tex
+++ b/toolsoftrade/toolsoftrade.tex
@@ -397,12 +397,20 @@ Note that this program carefully makes sure that only one of the threads
stores a value to variable \co{x} at a time.
Any situation in which one thread might be storing a value to a given
variable while some other thread either loads from or stores to that
-same variable is termed a ``data race''.
+same variable is termed a \emph{data race}.
Because the C language makes no guarantee that the results of a data race
will be in any way reasonable, we need some way of safely accessing
and modifying data concurrently, such as the locking primitives discussed
in the following section.
+But your data races are benign, you say?
+Well, maybe they are.
+But please do everyone (yourself included) a big favor and read
+\cref{sec:toolsoftrade:Shared-Variable Shenanigans}
+very carefully.
+As compilers optimize more and more aggressively, there are fewer and
+fewer truly benign data races.
+
\QuickQuiz{
If the C language makes no guarantees in presence of a data
race, then why does the Linux kernel have so many data races?
^ permalink raw reply related [flat|nested] 12+ messages in thread
* Re: [PATCH 3/3 -perfbook] debugging: Fix typo
2021-03-20 19:23 ` Paul E. McKenney
@ 2021-03-21 1:03 ` Akira Yokosawa
2021-03-21 5:48 ` Paul E. McKenney
2021-03-22 5:50 ` Akira Yokosawa
0 siblings, 2 replies; 12+ messages in thread
From: Akira Yokosawa @ 2021-03-21 1:03 UTC (permalink / raw
To: Paul E. McKenney; +Cc: perfbook, Akira Yokosawa
On Sat, 20 Mar 2021 12:23:23 -0700, Paul E. McKenney wrote:
> On Sun, Mar 21, 2021 at 12:50:43AM +0900, Akira Yokosawa wrote:
>> On Sun, 21 Mar 2021 00:24:46 +0900, Akira Yokosawa wrote:
>>> Signed-off-by: Akira Yokosawa <akiyks@gmail.com>
>>> ---
>>> debugging/debugging.tex | 2 +-
>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/debugging/debugging.tex b/debugging/debugging.tex
>>> index fd52d9e7..3f697f58 100644
>>> --- a/debugging/debugging.tex
>>> +++ b/debugging/debugging.tex
>>> @@ -755,7 +755,7 @@ access to data.
>>> The Kernel Concurrency Sanitizer (KCSAN)~\cite{JonathanCorbet2019KCSAN}
>>> uses existing markings such as \co{READ_ONCE()} and \co{WRITE_ONCE()}
>>> to determine which concurrent accesses deserve warning messages.
>>> -KCSAN has a significant false-positive rate, especially in from the
>>> +KCSAN has a significant false-positive rate, especially from the
>>> viewpoint of developers thinking in terms of C as assembly language
>>> with additional syntax.
>>> KCSAN therefore provides a \co{data_race()} construct to forgive
>>>
>>
>> Paul,
>>
>> I caught this one while searching the usage of "data race" in perfbook.
>> I thought "data race" also deserves an entry in Glossaries, especially
>> because our use of "data race" is heavily related to compiler
>> optimizations and somewhat stricter than the common definition
>> found on the web.
>>
>> The first of data race in Section 4.2.2 (just before QQ4.8) does
>> not (explicitly) talk about optimizations.
>>
>> Would it be possible for you to come up with some concise definition
>> of data race which will fit as an entry in the Glossaries?
>
> How about like the following?
Looks good to me!
Note on the index entry:
My experiment on the way to annotate index entries can manage automatic
capitalization of only the first letter in indexed words/terms.
So you won't need to take care of them.
And I'll get rid of direct uses of \index{} macro.
Will start rebasing those experiment soon after the release of
second edition.
Thanks, Akira
>
> Thanx, Paul
>
> ------------------------------------------------------------------------
>
> commit da6dcf306cf2eb05324c306bbed230cc543fc426
> Author: Paul E. McKenney <paulmck@kernel.org>
> Date: Sat Mar 20 12:21:07 2021 -0700
>
> toolsoftrade,glossary: Explain data races
>
> While in the area, make the cases of index entries consistent,
> fixing my copy-pasta from the glossary entry.
>
> Reported-by: Akira Yokosawa <akiyks@gmail.com>
> Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
>
> diff --git a/glossary.tex b/glossary.tex
> index c6c9c62..e6aa612 100644
> --- a/glossary.tex
> +++ b/glossary.tex
> @@ -38,13 +38,13 @@
> is atomic, because other CPUs will see either the old value or
> the new value, but are guaranteed not to see some mixed value
> containing some pieces of the new and old values.
> -\item[Atomic Read-Modify-Write Operation:]\index{Atomic Read-Modify-Write Operation}
> +\item[Atomic Read-Modify-Write Operation:]\index{Atomic read-modify-write operation}
> An atomic operation that both reads and writes memory is
> considered an atomic read-modify-write operation, or atomic RMW
> operation for short.
> Although the value written usually depends on the value read,
> \co{atomic_xchg()} is the exception that proves this rule.
> -\item[Bounded Wait Free:]\index{Bounded Wait Free}
> +\item[Bounded Wait Free:]\index{Bounded wait free}
> A forward-progress guarantee in which every thread makes
> progress within a specific finite period of time, the specific
> time being the bound.
> @@ -126,7 +126,7 @@
> \item[Capacity Miss:]\index{Capacity miss}
> A cache miss incurred because the corresponding CPU has recently
> accessed more data than will fit into the cache.
> -\item[Clash Free:]\index{Clash Free}
> +\item[Clash Free:]\index{Clash free}
> A forward-progress guarantee in which, in the absence of
> contention, at least one thread makes progress within a finite
> period of time.
> @@ -170,7 +170,16 @@
> increasing numbers of CPUs as the number of instances of
> data grows.
> Contrast with ``code locking''.
> -\item[Deadlock Free:]\index{Deadlock Free}
> +\item[Data Race:]\index{Data race}
> + A race condition in which several CPUs or threads access
> + a variable concurrently, and in which at least one of those
> + accesses is a store and at least one of those accesses
> + is unmarked.
> + It is important to note that while the presence of data races
> + often indicates the presence of bugs, the absence of data races
> + in no way implies the absence of bugs.
> + (See ``Marked access''.)
> +\item[Deadlock Free:]\index{Deadlock free}
> A forward-progress guarantee in which, in the absence of
> failures, at least one thread makes progress within a finite
> period of time.
> @@ -226,7 +235,7 @@
> Since RCU read-side critical sections by definition cannot
> contain quiescent states, these two definitions are almost
> always interchangeable.
> -\item[Hazard Pointer:]\index{Hazard Pointer}
> +\item[Hazard Pointer:]\index{Hazard pointer}
> A scalable counterpart to a reference counter in which an
> object's reference count is represented implicitly by a count
> of the number of special hazard pointers referencing that object.
> @@ -284,9 +293,21 @@
> used so heavily that there is often a CPU waiting on it.
> Reducing lock contention is often a concern when designing
> parallel algorithms and when implementing parallel programs.
> -\item[Lock Free:]\index{Lock Free}
> +\item[Lock Free:]\index{Lock free}
> A forward-progress guarantee in which at least one thread makes
> progress within a finite period of time.
> +\item[Marked Access:]\index{Marked access}
> + A source-code memory access that uses a special function or
> + macro, such as \co{READ_ONCE()}, \co{WRITE_ONCE()},
> + \co{atomic_inc()}, and so on, in order to protect that access
> + from compiler and/or hardware optimizations.
> + In contrast, an unmarked access simply mentions the name of
> + the object being accessed, so that in the following, line~2
> + is the unmarked equivalent of line~1:
> + \begin{VerbatimN}
> + WRITE_ONCE(a, READ_ONCE(b) + READ_ONCE(c));
> + a = b + c;
> + \end{VerbatimN}
> \item[Memory:]\index{Memory}
> From the viewpoint of memory models, the main memory,
> caches, and store buffers in which values might be stored.
> @@ -345,7 +366,7 @@
> \item[NUMA Node:]\index{NUMA node}
> A group of closely placed CPUs and associated memory within
> a larger NUMA machines.
> -\item[Obstruction Free:]\index{Obstruction Free}
> +\item[Obstruction Free:]\index{Obstruction free}
> A forward-progress guarantee in which, in the absence of
> contention, every thread makes progress within a finite
> period of time.
> @@ -428,7 +449,7 @@
> wait for the writer to release the lock.
> A key concern for reader-writer locks is ``fairness'':
> can an unending stream of readers starve a writer or vice versa.
> -\item[Real Time:]\index{Real Time}
> +\item[Real Time:]\index{Real time}
> A situation in which getting the correct result is not sufficient,
> but where this result must also be obtained within a given amount
> of time.
> @@ -437,7 +458,7 @@
> additional resources.
> For parallel computing, the additional resources are usually
> additional CPUs.
> -\item[Sequence Lock:]\index{Sequence Lock}
> +\item[Sequence Lock:]\index{Sequence lock}
> A reader-writer synchronization mechanism in which readers
> retry their operations if a writer was present.
> \item[Sequential Consistency:]\index{Sequential consistency}
> @@ -445,7 +466,7 @@
> in an order consistent with
> a single global order, and where each CPU's memory references
> appear to all CPUs to occur in program order.
> -\item[Starvation Free:]\index{Starvation Free}
> +\item[Starvation Free:]\index{Starvation free}
> A forward-progress guarantee in which, in the absence of
> failures, every thread makes progress within a finite
> period of time.
> @@ -483,7 +504,7 @@
> they understand completely and are therefore comfortable teaching.
> \item[Throughput:]\index{Throughput}
> A performance metric featuring work items completed per unit time.
> -\item[Transactional Lock Elision (TLE):]\index{Transactional Lock Elision (TLE)}
> +\item[Transactional Lock Elision (TLE):]\index{Transactional lock elision (TLE)}
> The use of transactional memory to emulate locking.
> Synchronization is instead carried out by conflicting accesses
> to the data to be protected by the lock.
> @@ -503,7 +524,7 @@
> In the 1960s through the 1980s, only supercomputers had vector
> capabilities, but the advent of MMX in x86 CPUs and VMX in
> PowerPC CPUs brought vector processing to the masses.
> -\item[Wait Free:]\index{Wait Free}
> +\item[Wait Free:]\index{Wait free}
> A forward-progress guarantee in which every thread makes
> progress within a finite period of time.
> \item[Write Miss:]\index{Write miss}
> diff --git a/toolsoftrade/toolsoftrade.tex b/toolsoftrade/toolsoftrade.tex
> index 1f667e0..9e0838c 100644
> --- a/toolsoftrade/toolsoftrade.tex
> +++ b/toolsoftrade/toolsoftrade.tex
> @@ -397,12 +397,20 @@ Note that this program carefully makes sure that only one of the threads
> stores a value to variable \co{x} at a time.
> Any situation in which one thread might be storing a value to a given
> variable while some other thread either loads from or stores to that
> -same variable is termed a ``data race''.
> +same variable is termed a \emph{data race}.
> Because the C language makes no guarantee that the results of a data race
> will be in any way reasonable, we need some way of safely accessing
> and modifying data concurrently, such as the locking primitives discussed
> in the following section.
>
> +But your data races are benign, you say?
> +Well, maybe they are.
> +But please do everyone (yourself included) a big favor and read
> +\cref{sec:toolsoftrade:Shared-Variable Shenanigans}
> +very carefully.
> +As compilers optimize more and more aggressively, there are fewer and
> +fewer truly benign data races.
> +
> \QuickQuiz{
> If the C language makes no guarantees in presence of a data
> race, then why does the Linux kernel have so many data races?
>
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH 3/3 -perfbook] debugging: Fix typo
2021-03-21 1:03 ` Akira Yokosawa
@ 2021-03-21 5:48 ` Paul E. McKenney
2021-03-22 5:50 ` Akira Yokosawa
1 sibling, 0 replies; 12+ messages in thread
From: Paul E. McKenney @ 2021-03-21 5:48 UTC (permalink / raw
To: Akira Yokosawa; +Cc: perfbook
On Sun, Mar 21, 2021 at 10:03:49AM +0900, Akira Yokosawa wrote:
> On Sat, 20 Mar 2021 12:23:23 -0700, Paul E. McKenney wrote:
> > On Sun, Mar 21, 2021 at 12:50:43AM +0900, Akira Yokosawa wrote:
> >> On Sun, 21 Mar 2021 00:24:46 +0900, Akira Yokosawa wrote:
> >>> Signed-off-by: Akira Yokosawa <akiyks@gmail.com>
> >>> ---
> >>> debugging/debugging.tex | 2 +-
> >>> 1 file changed, 1 insertion(+), 1 deletion(-)
> >>>
> >>> diff --git a/debugging/debugging.tex b/debugging/debugging.tex
> >>> index fd52d9e7..3f697f58 100644
> >>> --- a/debugging/debugging.tex
> >>> +++ b/debugging/debugging.tex
> >>> @@ -755,7 +755,7 @@ access to data.
> >>> The Kernel Concurrency Sanitizer (KCSAN)~\cite{JonathanCorbet2019KCSAN}
> >>> uses existing markings such as \co{READ_ONCE()} and \co{WRITE_ONCE()}
> >>> to determine which concurrent accesses deserve warning messages.
> >>> -KCSAN has a significant false-positive rate, especially in from the
> >>> +KCSAN has a significant false-positive rate, especially from the
> >>> viewpoint of developers thinking in terms of C as assembly language
> >>> with additional syntax.
> >>> KCSAN therefore provides a \co{data_race()} construct to forgive
> >>>
> >>
> >> Paul,
> >>
> >> I caught this one while searching the usage of "data race" in perfbook.
> >> I thought "data race" also deserves an entry in Glossaries, especially
> >> because our use of "data race" is heavily related to compiler
> >> optimizations and somewhat stricter than the common definition
> >> found on the web.
> >>
> >> The first of data race in Section 4.2.2 (just before QQ4.8) does
> >> not (explicitly) talk about optimizations.
> >>
> >> Would it be possible for you to come up with some concise definition
> >> of data race which will fit as an entry in the Glossaries?
> >
> > How about like the following?
>
> Looks good to me!
Very good, and I have pushed it out.
> Note on the index entry:
>
> My experiment on the way to annotate index entries can manage automatic
> capitalization of only the first letter in indexed words/terms.
> So you won't need to take care of them.
>
> And I'll get rid of direct uses of \index{} macro.
>
> Will start rebasing those experiment soon after the release of
> second edition.
Sounds very good!
Thanx, Paul
> Thanks, Akira
>
> >
> > Thanx, Paul
> >
> > ------------------------------------------------------------------------
> >
> > commit da6dcf306cf2eb05324c306bbed230cc543fc426
> > Author: Paul E. McKenney <paulmck@kernel.org>
> > Date: Sat Mar 20 12:21:07 2021 -0700
> >
> > toolsoftrade,glossary: Explain data races
> >
> > While in the area, make the cases of index entries consistent,
> > fixing my copy-pasta from the glossary entry.
> >
> > Reported-by: Akira Yokosawa <akiyks@gmail.com>
> > Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
> >
> > diff --git a/glossary.tex b/glossary.tex
> > index c6c9c62..e6aa612 100644
> > --- a/glossary.tex
> > +++ b/glossary.tex
> > @@ -38,13 +38,13 @@
> > is atomic, because other CPUs will see either the old value or
> > the new value, but are guaranteed not to see some mixed value
> > containing some pieces of the new and old values.
> > -\item[Atomic Read-Modify-Write Operation:]\index{Atomic Read-Modify-Write Operation}
> > +\item[Atomic Read-Modify-Write Operation:]\index{Atomic read-modify-write operation}
> > An atomic operation that both reads and writes memory is
> > considered an atomic read-modify-write operation, or atomic RMW
> > operation for short.
> > Although the value written usually depends on the value read,
> > \co{atomic_xchg()} is the exception that proves this rule.
> > -\item[Bounded Wait Free:]\index{Bounded Wait Free}
> > +\item[Bounded Wait Free:]\index{Bounded wait free}
> > A forward-progress guarantee in which every thread makes
> > progress within a specific finite period of time, the specific
> > time being the bound.
> > @@ -126,7 +126,7 @@
> > \item[Capacity Miss:]\index{Capacity miss}
> > A cache miss incurred because the corresponding CPU has recently
> > accessed more data than will fit into the cache.
> > -\item[Clash Free:]\index{Clash Free}
> > +\item[Clash Free:]\index{Clash free}
> > A forward-progress guarantee in which, in the absence of
> > contention, at least one thread makes progress within a finite
> > period of time.
> > @@ -170,7 +170,16 @@
> > increasing numbers of CPUs as the number of instances of
> > data grows.
> > Contrast with ``code locking''.
> > -\item[Deadlock Free:]\index{Deadlock Free}
> > +\item[Data Race:]\index{Data race}
> > + A race condition in which several CPUs or threads access
> > + a variable concurrently, and in which at least one of those
> > + accesses is a store and at least one of those accesses
> > + is unmarked.
> > + It is important to note that while the presence of data races
> > + often indicates the presence of bugs, the absence of data races
> > + in no way implies the absence of bugs.
> > + (See ``Marked access''.)
> > +\item[Deadlock Free:]\index{Deadlock free}
> > A forward-progress guarantee in which, in the absence of
> > failures, at least one thread makes progress within a finite
> > period of time.
> > @@ -226,7 +235,7 @@
> > Since RCU read-side critical sections by definition cannot
> > contain quiescent states, these two definitions are almost
> > always interchangeable.
> > -\item[Hazard Pointer:]\index{Hazard Pointer}
> > +\item[Hazard Pointer:]\index{Hazard pointer}
> > A scalable counterpart to a reference counter in which an
> > object's reference count is represented implicitly by a count
> > of the number of special hazard pointers referencing that object.
> > @@ -284,9 +293,21 @@
> > used so heavily that there is often a CPU waiting on it.
> > Reducing lock contention is often a concern when designing
> > parallel algorithms and when implementing parallel programs.
> > -\item[Lock Free:]\index{Lock Free}
> > +\item[Lock Free:]\index{Lock free}
> > A forward-progress guarantee in which at least one thread makes
> > progress within a finite period of time.
> > +\item[Marked Access:]\index{Marked access}
> > + A source-code memory access that uses a special function or
> > + macro, such as \co{READ_ONCE()}, \co{WRITE_ONCE()},
> > + \co{atomic_inc()}, and so on, in order to protect that access
> > + from compiler and/or hardware optimizations.
> > + In contrast, an unmarked access simply mentions the name of
> > + the object being accessed, so that in the following, line~2
> > + is the unmarked equivalent of line~1:
> > + \begin{VerbatimN}
> > + WRITE_ONCE(a, READ_ONCE(b) + READ_ONCE(c));
> > + a = b + c;
> > + \end{VerbatimN}
> > \item[Memory:]\index{Memory}
> > From the viewpoint of memory models, the main memory,
> > caches, and store buffers in which values might be stored.
> > @@ -345,7 +366,7 @@
> > \item[NUMA Node:]\index{NUMA node}
> > A group of closely placed CPUs and associated memory within
> > a larger NUMA machines.
> > -\item[Obstruction Free:]\index{Obstruction Free}
> > +\item[Obstruction Free:]\index{Obstruction free}
> > A forward-progress guarantee in which, in the absence of
> > contention, every thread makes progress within a finite
> > period of time.
> > @@ -428,7 +449,7 @@
> > wait for the writer to release the lock.
> > A key concern for reader-writer locks is ``fairness'':
> > can an unending stream of readers starve a writer or vice versa.
> > -\item[Real Time:]\index{Real Time}
> > +\item[Real Time:]\index{Real time}
> > A situation in which getting the correct result is not sufficient,
> > but where this result must also be obtained within a given amount
> > of time.
> > @@ -437,7 +458,7 @@
> > additional resources.
> > For parallel computing, the additional resources are usually
> > additional CPUs.
> > -\item[Sequence Lock:]\index{Sequence Lock}
> > +\item[Sequence Lock:]\index{Sequence lock}
> > A reader-writer synchronization mechanism in which readers
> > retry their operations if a writer was present.
> > \item[Sequential Consistency:]\index{Sequential consistency}
> > @@ -445,7 +466,7 @@
> > in an order consistent with
> > a single global order, and where each CPU's memory references
> > appear to all CPUs to occur in program order.
> > -\item[Starvation Free:]\index{Starvation Free}
> > +\item[Starvation Free:]\index{Starvation free}
> > A forward-progress guarantee in which, in the absence of
> > failures, every thread makes progress within a finite
> > period of time.
> > @@ -483,7 +504,7 @@
> > they understand completely and are therefore comfortable teaching.
> > \item[Throughput:]\index{Throughput}
> > A performance metric featuring work items completed per unit time.
> > -\item[Transactional Lock Elision (TLE):]\index{Transactional Lock Elision (TLE)}
> > +\item[Transactional Lock Elision (TLE):]\index{Transactional lock elision (TLE)}
> > The use of transactional memory to emulate locking.
> > Synchronization is instead carried out by conflicting accesses
> > to the data to be protected by the lock.
> > @@ -503,7 +524,7 @@
> > In the 1960s through the 1980s, only supercomputers had vector
> > capabilities, but the advent of MMX in x86 CPUs and VMX in
> > PowerPC CPUs brought vector processing to the masses.
> > -\item[Wait Free:]\index{Wait Free}
> > +\item[Wait Free:]\index{Wait free}
> > A forward-progress guarantee in which every thread makes
> > progress within a finite period of time.
> > \item[Write Miss:]\index{Write miss}
> > diff --git a/toolsoftrade/toolsoftrade.tex b/toolsoftrade/toolsoftrade.tex
> > index 1f667e0..9e0838c 100644
> > --- a/toolsoftrade/toolsoftrade.tex
> > +++ b/toolsoftrade/toolsoftrade.tex
> > @@ -397,12 +397,20 @@ Note that this program carefully makes sure that only one of the threads
> > stores a value to variable \co{x} at a time.
> > Any situation in which one thread might be storing a value to a given
> > variable while some other thread either loads from or stores to that
> > -same variable is termed a ``data race''.
> > +same variable is termed a \emph{data race}.
> > Because the C language makes no guarantee that the results of a data race
> > will be in any way reasonable, we need some way of safely accessing
> > and modifying data concurrently, such as the locking primitives discussed
> > in the following section.
> >
> > +But your data races are benign, you say?
> > +Well, maybe they are.
> > +But please do everyone (yourself included) a big favor and read
> > +\cref{sec:toolsoftrade:Shared-Variable Shenanigans}
> > +very carefully.
> > +As compilers optimize more and more aggressively, there are fewer and
> > +fewer truly benign data races.
> > +
> > \QuickQuiz{
> > If the C language makes no guarantees in presence of a data
> > race, then why does the Linux kernel have so many data races?
> >
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH 3/3 -perfbook] debugging: Fix typo
2021-03-21 1:03 ` Akira Yokosawa
2021-03-21 5:48 ` Paul E. McKenney
@ 2021-03-22 5:50 ` Akira Yokosawa
2021-03-22 15:15 ` Paul E. McKenney
1 sibling, 1 reply; 12+ messages in thread
From: Akira Yokosawa @ 2021-03-22 5:50 UTC (permalink / raw
To: Paul E. McKenney; +Cc: perfbook, Akira Yokosawa
On Sun, 21 Mar 2021 10:03:49 +0900, Akira Yokosawa wrote:
> On Sat, 20 Mar 2021 12:23:23 -0700, Paul E. McKenney wrote:
>> On Sun, Mar 21, 2021 at 12:50:43AM +0900, Akira Yokosawa wrote:
>>> On Sun, 21 Mar 2021 00:24:46 +0900, Akira Yokosawa wrote:
>>>> Signed-off-by: Akira Yokosawa <akiyks@gmail.com>
>>>> ---
>>>> debugging/debugging.tex | 2 +-
>>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>>
>>>> diff --git a/debugging/debugging.tex b/debugging/debugging.tex
>>>> index fd52d9e7..3f697f58 100644
>>>> --- a/debugging/debugging.tex
>>>> +++ b/debugging/debugging.tex
>>>> @@ -755,7 +755,7 @@ access to data.
>>>> The Kernel Concurrency Sanitizer (KCSAN)~\cite{JonathanCorbet2019KCSAN}
>>>> uses existing markings such as \co{READ_ONCE()} and \co{WRITE_ONCE()}
>>>> to determine which concurrent accesses deserve warning messages.
>>>> -KCSAN has a significant false-positive rate, especially in from the
>>>> +KCSAN has a significant false-positive rate, especially from the
>>>> viewpoint of developers thinking in terms of C as assembly language
>>>> with additional syntax.
>>>> KCSAN therefore provides a \co{data_race()} construct to forgive
>>>>
>>>
>>> Paul,
>>>
>>> I caught this one while searching the usage of "data race" in perfbook.
>>> I thought "data race" also deserves an entry in Glossaries, especially
>>> because our use of "data race" is heavily related to compiler
>>> optimizations and somewhat stricter than the common definition
>>> found on the web.
>>>
>>> The first of data race in Section 4.2.2 (just before QQ4.8) does
>>> not (explicitly) talk about optimizations.
>>>
>>> Would it be possible for you to come up with some concise definition
>>> of data race which will fit as an entry in the Glossaries?
>>
>> How about like the following?
>
> Looks good to me!
It looked good, but I've found that there is no mention of "marked access"
in the whole text (except for Glossaries) in perfbook at the moment.
"Marked access", "unmarked load", and so on are used in
ordering.txt to be added to LKMM documentation.
They are going to appear in perfbook, I suppose.
How about adding "Plain Access" to the Glossaries as well
and amend the definition of "Data Race" using "plain access".
Thanks, Akira
>
> Note on the index entry:
>
> My experiment on the way to annotate index entries can manage automatic
> capitalization of only the first letter in indexed words/terms.
> So you won't need to take care of them.
>
> And I'll get rid of direct uses of \index{} macro.
>
> Will start rebasing those experiment soon after the release of
> second edition.
>
> Thanks, Akira
>
>>
>> Thanx, Paul
>>
>> ------------------------------------------------------------------------
[...]
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH 3/3 -perfbook] debugging: Fix typo
2021-03-22 5:50 ` Akira Yokosawa
@ 2021-03-22 15:15 ` Paul E. McKenney
2021-03-22 22:49 ` Akira Yokosawa
0 siblings, 1 reply; 12+ messages in thread
From: Paul E. McKenney @ 2021-03-22 15:15 UTC (permalink / raw
To: Akira Yokosawa; +Cc: perfbook
On Mon, Mar 22, 2021 at 02:50:38PM +0900, Akira Yokosawa wrote:
> On Sun, 21 Mar 2021 10:03:49 +0900, Akira Yokosawa wrote:
> > On Sat, 20 Mar 2021 12:23:23 -0700, Paul E. McKenney wrote:
> >> On Sun, Mar 21, 2021 at 12:50:43AM +0900, Akira Yokosawa wrote:
> >>> On Sun, 21 Mar 2021 00:24:46 +0900, Akira Yokosawa wrote:
> >>>> Signed-off-by: Akira Yokosawa <akiyks@gmail.com>
> >>>> ---
> >>>> debugging/debugging.tex | 2 +-
> >>>> 1 file changed, 1 insertion(+), 1 deletion(-)
> >>>>
> >>>> diff --git a/debugging/debugging.tex b/debugging/debugging.tex
> >>>> index fd52d9e7..3f697f58 100644
> >>>> --- a/debugging/debugging.tex
> >>>> +++ b/debugging/debugging.tex
> >>>> @@ -755,7 +755,7 @@ access to data.
> >>>> The Kernel Concurrency Sanitizer (KCSAN)~\cite{JonathanCorbet2019KCSAN}
> >>>> uses existing markings such as \co{READ_ONCE()} and \co{WRITE_ONCE()}
> >>>> to determine which concurrent accesses deserve warning messages.
> >>>> -KCSAN has a significant false-positive rate, especially in from the
> >>>> +KCSAN has a significant false-positive rate, especially from the
> >>>> viewpoint of developers thinking in terms of C as assembly language
> >>>> with additional syntax.
> >>>> KCSAN therefore provides a \co{data_race()} construct to forgive
> >>>>
> >>>
> >>> Paul,
> >>>
> >>> I caught this one while searching the usage of "data race" in perfbook.
> >>> I thought "data race" also deserves an entry in Glossaries, especially
> >>> because our use of "data race" is heavily related to compiler
> >>> optimizations and somewhat stricter than the common definition
> >>> found on the web.
> >>>
> >>> The first of data race in Section 4.2.2 (just before QQ4.8) does
> >>> not (explicitly) talk about optimizations.
> >>>
> >>> Would it be possible for you to come up with some concise definition
> >>> of data race which will fit as an entry in the Glossaries?
> >>
> >> How about like the following?
> >
> > Looks good to me!
>
> It looked good, but I've found that there is no mention of "marked access"
> in the whole text (except for Glossaries) in perfbook at the moment.
>
> "Marked access", "unmarked load", and so on are used in
> ordering.txt to be added to LKMM documentation.
> They are going to appear in perfbook, I suppose.
>
> How about adding "Plain Access" to the Glossaries as well
> and amend the definition of "Data Race" using "plain access".
Good point! Like this?
Thanx, Paul
------------------------------------------------------------------------
commit b91c52cd1a93777ba91300d739e498bae9c49aea
Author: Paul E. McKenney <paulmck@kernel.org>
Date: Mon Mar 22 08:13:24 2021 -0700
Glossary: Add an entry for "Plain Access"
The book uses "plain access", so it deserves a glossary entry.
And of course "marked access" is its antonym, more or less.
Reported-by: Akira Yokosawa <akiyks@gmail.com>
Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
diff --git a/glossary.tex b/glossary.tex
index e6aa612..bbef382 100644
--- a/glossary.tex
+++ b/glossary.tex
@@ -174,11 +174,11 @@
A race condition in which several CPUs or threads access
a variable concurrently, and in which at least one of those
accesses is a store and at least one of those accesses
- is unmarked.
+ is a plain access.
It is important to note that while the presence of data races
often indicates the presence of bugs, the absence of data races
in no way implies the absence of bugs.
- (See ``Marked access''.)
+ (See ``Plain access''.)
\item[Deadlock Free:]\index{Deadlock free}
A forward-progress guarantee in which, in the absence of
failures, at least one thread makes progress within a finite
@@ -301,9 +301,9 @@
macro, such as \co{READ_ONCE()}, \co{WRITE_ONCE()},
\co{atomic_inc()}, and so on, in order to protect that access
from compiler and/or hardware optimizations.
- In contrast, an unmarked access simply mentions the name of
+ In contrast, a plain access simply mentions the name of
the object being accessed, so that in the following, line~2
- is the unmarked equivalent of line~1:
+ is the plain-access equivalent of line~1:
\begin{VerbatimN}
WRITE_ONCE(a, READ_ONCE(b) + READ_ONCE(c));
a = b + c;
@@ -393,6 +393,10 @@
In the 1960s through the early 1980s, pipelined CPUs were the
province of supercomputers, but started appearing in microprocessors
(such as the 80486) in the late 1980s.
+\item[Plain Access:]\index{Plain access}
+ A source-code memory access that simply mentions the name of
+ the object being accessed.
+ (See ``Marked access''.)
\item[Process Consistency:]\index{Process consistency}
A memory-consistency model in which each CPU's stores appear to
occur in program order, but in which different CPUs might see
^ permalink raw reply related [flat|nested] 12+ messages in thread
* Re: [PATCH 3/3 -perfbook] debugging: Fix typo
2021-03-22 15:15 ` Paul E. McKenney
@ 2021-03-22 22:49 ` Akira Yokosawa
2021-03-23 5:15 ` Paul E. McKenney
0 siblings, 1 reply; 12+ messages in thread
From: Akira Yokosawa @ 2021-03-22 22:49 UTC (permalink / raw
To: Paul E. McKenney; +Cc: perfbook, Akira Yokosawa
On Mon, 22 Mar 2021 08:15:14 -0700, Paul E. McKenney wrote:
> On Mon, Mar 22, 2021 at 02:50:38PM +0900, Akira Yokosawa wrote:
>> On Sun, 21 Mar 2021 10:03:49 +0900, Akira Yokosawa wrote:
>>> On Sat, 20 Mar 2021 12:23:23 -0700, Paul E. McKenney wrote:
>>>> On Sun, Mar 21, 2021 at 12:50:43AM +0900, Akira Yokosawa wrote:
>>>>> On Sun, 21 Mar 2021 00:24:46 +0900, Akira Yokosawa wrote:
>>>>>> Signed-off-by: Akira Yokosawa <akiyks@gmail.com>
>>>>>> ---
>>>>>> debugging/debugging.tex | 2 +-
>>>>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>>>>
>>>>>> diff --git a/debugging/debugging.tex b/debugging/debugging.tex
>>>>>> index fd52d9e7..3f697f58 100644
>>>>>> --- a/debugging/debugging.tex
>>>>>> +++ b/debugging/debugging.tex
>>>>>> @@ -755,7 +755,7 @@ access to data.
>>>>>> The Kernel Concurrency Sanitizer (KCSAN)~\cite{JonathanCorbet2019KCSAN}
>>>>>> uses existing markings such as \co{READ_ONCE()} and \co{WRITE_ONCE()}
>>>>>> to determine which concurrent accesses deserve warning messages.
>>>>>> -KCSAN has a significant false-positive rate, especially in from the
>>>>>> +KCSAN has a significant false-positive rate, especially from the
>>>>>> viewpoint of developers thinking in terms of C as assembly language
>>>>>> with additional syntax.
>>>>>> KCSAN therefore provides a \co{data_race()} construct to forgive
>>>>>>
>>>>>
>>>>> Paul,
>>>>>
>>>>> I caught this one while searching the usage of "data race" in perfbook.
>>>>> I thought "data race" also deserves an entry in Glossaries, especially
>>>>> because our use of "data race" is heavily related to compiler
>>>>> optimizations and somewhat stricter than the common definition
>>>>> found on the web.
>>>>>
>>>>> The first of data race in Section 4.2.2 (just before QQ4.8) does
>>>>> not (explicitly) talk about optimizations.
>>>>>
>>>>> Would it be possible for you to come up with some concise definition
>>>>> of data race which will fit as an entry in the Glossaries?
>>>>
>>>> How about like the following?
>>>
>>> Looks good to me!
>>
>> It looked good, but I've found that there is no mention of "marked access"
>> in the whole text (except for Glossaries) in perfbook at the moment.
>>
>> "Marked access", "unmarked load", and so on are used in
>> ordering.txt to be added to LKMM documentation.
>> They are going to appear in perfbook, I suppose.
>>
>> How about adding "Plain Access" to the Glossaries as well
>> and amend the definition of "Data Race" using "plain access".
>
> Good point! Like this?
Thank you!
However, this patch conflicts with the removal of \index{} in glossary.tex
on my WIP branch.
Do you mind if I cherry pick it & rebase on the WIP branch, and
send you a pull request containing it later (maybe in a week or so)?
Thanks, Akira
>
> Thanx, Paul
>
> ------------------------------------------------------------------------
>
> commit b91c52cd1a93777ba91300d739e498bae9c49aea
> Author: Paul E. McKenney <paulmck@kernel.org>
> Date: Mon Mar 22 08:13:24 2021 -0700
>
> Glossary: Add an entry for "Plain Access"
>
> The book uses "plain access", so it deserves a glossary entry.
> And of course "marked access" is its antonym, more or less.
>
> Reported-by: Akira Yokosawa <akiyks@gmail.com>
> Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
>
> diff --git a/glossary.tex b/glossary.tex
> index e6aa612..bbef382 100644
> --- a/glossary.tex
> +++ b/glossary.tex
> @@ -174,11 +174,11 @@
> A race condition in which several CPUs or threads access
> a variable concurrently, and in which at least one of those
> accesses is a store and at least one of those accesses
> - is unmarked.
> + is a plain access.
> It is important to note that while the presence of data races
> often indicates the presence of bugs, the absence of data races
> in no way implies the absence of bugs.
> - (See ``Marked access''.)
> + (See ``Plain access''.)
> \item[Deadlock Free:]\index{Deadlock free}
> A forward-progress guarantee in which, in the absence of
> failures, at least one thread makes progress within a finite
> @@ -301,9 +301,9 @@
> macro, such as \co{READ_ONCE()}, \co{WRITE_ONCE()},
> \co{atomic_inc()}, and so on, in order to protect that access
> from compiler and/or hardware optimizations.
> - In contrast, an unmarked access simply mentions the name of
> + In contrast, a plain access simply mentions the name of
> the object being accessed, so that in the following, line~2
> - is the unmarked equivalent of line~1:
> + is the plain-access equivalent of line~1:
> \begin{VerbatimN}
> WRITE_ONCE(a, READ_ONCE(b) + READ_ONCE(c));
> a = b + c;
> @@ -393,6 +393,10 @@
> In the 1960s through the early 1980s, pipelined CPUs were the
> province of supercomputers, but started appearing in microprocessors
> (such as the 80486) in the late 1980s.
> +\item[Plain Access:]\index{Plain access}
> + A source-code memory access that simply mentions the name of
> + the object being accessed.
> + (See ``Marked access''.)
> \item[Process Consistency:]\index{Process consistency}
> A memory-consistency model in which each CPU's stores appear to
> occur in program order, but in which different CPUs might see
>
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH 3/3 -perfbook] debugging: Fix typo
2021-03-22 22:49 ` Akira Yokosawa
@ 2021-03-23 5:15 ` Paul E. McKenney
0 siblings, 0 replies; 12+ messages in thread
From: Paul E. McKenney @ 2021-03-23 5:15 UTC (permalink / raw
To: Akira Yokosawa; +Cc: perfbook
On Tue, Mar 23, 2021 at 07:49:50AM +0900, Akira Yokosawa wrote:
> On Mon, 22 Mar 2021 08:15:14 -0700, Paul E. McKenney wrote:
> > On Mon, Mar 22, 2021 at 02:50:38PM +0900, Akira Yokosawa wrote:
> >> On Sun, 21 Mar 2021 10:03:49 +0900, Akira Yokosawa wrote:
> >>> On Sat, 20 Mar 2021 12:23:23 -0700, Paul E. McKenney wrote:
> >>>> On Sun, Mar 21, 2021 at 12:50:43AM +0900, Akira Yokosawa wrote:
> >>>>> On Sun, 21 Mar 2021 00:24:46 +0900, Akira Yokosawa wrote:
> >>>>>> Signed-off-by: Akira Yokosawa <akiyks@gmail.com>
> >>>>>> ---
> >>>>>> debugging/debugging.tex | 2 +-
> >>>>>> 1 file changed, 1 insertion(+), 1 deletion(-)
> >>>>>>
> >>>>>> diff --git a/debugging/debugging.tex b/debugging/debugging.tex
> >>>>>> index fd52d9e7..3f697f58 100644
> >>>>>> --- a/debugging/debugging.tex
> >>>>>> +++ b/debugging/debugging.tex
> >>>>>> @@ -755,7 +755,7 @@ access to data.
> >>>>>> The Kernel Concurrency Sanitizer (KCSAN)~\cite{JonathanCorbet2019KCSAN}
> >>>>>> uses existing markings such as \co{READ_ONCE()} and \co{WRITE_ONCE()}
> >>>>>> to determine which concurrent accesses deserve warning messages.
> >>>>>> -KCSAN has a significant false-positive rate, especially in from the
> >>>>>> +KCSAN has a significant false-positive rate, especially from the
> >>>>>> viewpoint of developers thinking in terms of C as assembly language
> >>>>>> with additional syntax.
> >>>>>> KCSAN therefore provides a \co{data_race()} construct to forgive
> >>>>>>
> >>>>>
> >>>>> Paul,
> >>>>>
> >>>>> I caught this one while searching the usage of "data race" in perfbook.
> >>>>> I thought "data race" also deserves an entry in Glossaries, especially
> >>>>> because our use of "data race" is heavily related to compiler
> >>>>> optimizations and somewhat stricter than the common definition
> >>>>> found on the web.
> >>>>>
> >>>>> The first of data race in Section 4.2.2 (just before QQ4.8) does
> >>>>> not (explicitly) talk about optimizations.
> >>>>>
> >>>>> Would it be possible for you to come up with some concise definition
> >>>>> of data race which will fit as an entry in the Glossaries?
> >>>>
> >>>> How about like the following?
> >>>
> >>> Looks good to me!
> >>
> >> It looked good, but I've found that there is no mention of "marked access"
> >> in the whole text (except for Glossaries) in perfbook at the moment.
> >>
> >> "Marked access", "unmarked load", and so on are used in
> >> ordering.txt to be added to LKMM documentation.
> >> They are going to appear in perfbook, I suppose.
> >>
> >> How about adding "Plain Access" to the Glossaries as well
> >> and amend the definition of "Data Race" using "plain access".
> >
> > Good point! Like this?
>
> Thank you!
>
> However, this patch conflicts with the removal of \index{} in glossary.tex
> on my WIP branch.
> Do you mind if I cherry pick it & rebase on the WIP branch, and
> send you a pull request containing it later (maybe in a week or so)?
Works for me!
Thanx, Paul
> Thanks, Akira
>
> >
> > Thanx, Paul
> >
> > ------------------------------------------------------------------------
> >
> > commit b91c52cd1a93777ba91300d739e498bae9c49aea
> > Author: Paul E. McKenney <paulmck@kernel.org>
> > Date: Mon Mar 22 08:13:24 2021 -0700
> >
> > Glossary: Add an entry for "Plain Access"
> >
> > The book uses "plain access", so it deserves a glossary entry.
> > And of course "marked access" is its antonym, more or less.
> >
> > Reported-by: Akira Yokosawa <akiyks@gmail.com>
> > Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
> >
> > diff --git a/glossary.tex b/glossary.tex
> > index e6aa612..bbef382 100644
> > --- a/glossary.tex
> > +++ b/glossary.tex
> > @@ -174,11 +174,11 @@
> > A race condition in which several CPUs or threads access
> > a variable concurrently, and in which at least one of those
> > accesses is a store and at least one of those accesses
> > - is unmarked.
> > + is a plain access.
> > It is important to note that while the presence of data races
> > often indicates the presence of bugs, the absence of data races
> > in no way implies the absence of bugs.
> > - (See ``Marked access''.)
> > + (See ``Plain access''.)
> > \item[Deadlock Free:]\index{Deadlock free}
> > A forward-progress guarantee in which, in the absence of
> > failures, at least one thread makes progress within a finite
> > @@ -301,9 +301,9 @@
> > macro, such as \co{READ_ONCE()}, \co{WRITE_ONCE()},
> > \co{atomic_inc()}, and so on, in order to protect that access
> > from compiler and/or hardware optimizations.
> > - In contrast, an unmarked access simply mentions the name of
> > + In contrast, a plain access simply mentions the name of
> > the object being accessed, so that in the following, line~2
> > - is the unmarked equivalent of line~1:
> > + is the plain-access equivalent of line~1:
> > \begin{VerbatimN}
> > WRITE_ONCE(a, READ_ONCE(b) + READ_ONCE(c));
> > a = b + c;
> > @@ -393,6 +393,10 @@
> > In the 1960s through the early 1980s, pipelined CPUs were the
> > province of supercomputers, but started appearing in microprocessors
> > (such as the 80486) in the late 1980s.
> > +\item[Plain Access:]\index{Plain access}
> > + A source-code memory access that simply mentions the name of
> > + the object being accessed.
> > + (See ``Marked access''.)
> > \item[Process Consistency:]\index{Process consistency}
> > A memory-consistency model in which each CPU's stores appear to
> > occur in program order, but in which different CPUs might see
> >
^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2021-03-23 5:15 UTC | newest]
Thread overview: 12+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2021-03-20 15:16 [PATCH 1/3 -perfbook] bib/hw: Improve looks of WilliamGWong2019CCIX-CXL's title Akira Yokosawa
2021-03-20 15:23 ` [PATCH 2/3 -perfbook] together/refcnt: Adjust tense with 'have released' Akira Yokosawa
2021-03-20 19:03 ` Paul E. McKenney
2021-03-20 15:24 ` [PATCH 3/3 -perfbook] debugging: Fix typo Akira Yokosawa
2021-03-20 15:50 ` Akira Yokosawa
2021-03-20 19:23 ` Paul E. McKenney
2021-03-21 1:03 ` Akira Yokosawa
2021-03-21 5:48 ` Paul E. McKenney
2021-03-22 5:50 ` Akira Yokosawa
2021-03-22 15:15 ` Paul E. McKenney
2021-03-22 22:49 ` Akira Yokosawa
2021-03-23 5:15 ` Paul E. McKenney
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.