* [PATCH] datastruct.tex: fix some minor typos
@ 2020-02-12 14:35 Junchang Wang
2020-02-13 15:28 ` Akira Yokosawa
0 siblings, 1 reply; 6+ messages in thread
From: Junchang Wang @ 2020-02-12 14:35 UTC (permalink / raw)
To: perfbook
Signed-off-by: Junchang Wang <junchangwang@gmail.com>
---
Hi Paul,
I'm reading the latest version of the perfbook and this patch contains fixes to
some typos in Section Data Structures. Hope it helps.
Thanks,
--Junchang
--
datastruct/datastruct.tex | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/datastruct/datastruct.tex b/datastruct/datastruct.tex
index 4b62471..e21952b 100644
--- a/datastruct/datastruct.tex
+++ b/datastruct/datastruct.tex
@@ -700,7 +700,7 @@ Of course, it is quite possible that the differences in lookup performance
are affected by the differences in update rates.
One way to check this is to artificially throttle the update rates of
per-bucket locking and hazard pointers to match that of RCU.
-Doing so does not significantly improve the lookup performace of
+Doing so does not significantly improve the lookup performance of
per-bucket locking, nor does it close the gap between hazard pointers
and RCU.
However, removing the read-side memory barriers from hazard pointers
@@ -800,8 +800,8 @@ scalability, external consistency, or all of the above.
\section{Non-Partitionable Data Structures}
\label{sec:datastruct:Non-Partitionable Data Structures}
%
-\epigraph{Undertake somthing difficult, otherwise you will never grow.}
- {\emph{Ronald E.~Osburn}}
+\epigraph{Undertake something difficult, otherwise you will never grow.}
+ {\emph{Ronald E.~Osborn}}
\begin{figure}[tb]
\centering
@@ -1063,7 +1063,7 @@ Otherwise, a concurrent resize operation has already distributed this
bucket, so line~\lnref{new_hashtbl} proceeds to the new hash table,
line~\lnref{get_newbkt} selects the bucket corresponding to the key,
and line~\lnref{acq_newbkt} acquires the bucket's lock.
-\Clnref{lsp1b}{lsp1e} store the bucket pointer and
+\Clnrefrange{lsp1b}{lsp1e} store the bucket pointer and
pointer-set index into their respective fields in the
\co{ht_lock_state} structure, which again communicates this information to
\co{hashtab_add()}, \co{hashtab_del()}, and \co{hashtab_unlock_mod()}.
--
2.7.4
^ permalink raw reply related [flat|nested] 6+ messages in thread
* Re: [PATCH] datastruct.tex: fix some minor typos
2020-02-12 14:35 [PATCH] datastruct.tex: fix some minor typos Junchang Wang
@ 2020-02-13 15:28 ` Akira Yokosawa
2020-02-13 19:19 ` Paul E. McKenney
2020-02-14 0:40 ` Junchang Wang
0 siblings, 2 replies; 6+ messages in thread
From: Akira Yokosawa @ 2020-02-13 15:28 UTC (permalink / raw)
To: Junchang Wang; +Cc: perfbook, junchangwang
Hi, Junchang,
On Wed, 12 Feb 2020 22:35:15 +0800, Junchang Wang wrote:
> Signed-off-by: Junchang Wang <junchangwang@gmail.com>
> ---
>
> Hi Paul,
>
> I'm reading the latest version of the perfbook and this patch contains fixes to
> some typos in Section Data Structures. Hope it helps.
>
> Thanks,
> --Junchang
>
> --
> datastruct/datastruct.tex | 8 ++++----
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/datastruct/datastruct.tex b/datastruct/datastruct.tex
> index 4b62471..e21952b 100644
> --- a/datastruct/datastruct.tex
> +++ b/datastruct/datastruct.tex
> @@ -700,7 +700,7 @@ Of course, it is quite possible that the differences in lookup performance
> are affected by the differences in update rates.
> One way to check this is to artificially throttle the update rates of
> per-bucket locking and hazard pointers to match that of RCU.
> -Doing so does not significantly improve the lookup performace of
> +Doing so does not significantly improve the lookup performance of
> per-bucket locking, nor does it close the gap between hazard pointers
> and RCU.
> However, removing the read-side memory barriers from hazard pointers
> @@ -800,8 +800,8 @@ scalability, external consistency, or all of the above.
> \section{Non-Partitionable Data Structures}
> \label{sec:datastruct:Non-Partitionable Data Structures}
> %
> -\epigraph{Undertake somthing difficult, otherwise you will never grow.}
> - {\emph{Ronald E.~Osburn}}
> +\epigraph{Undertake something difficult, otherwise you will never grow.}
> + {\emph{Ronald E.~Osborn}}
>
> \begin{figure}[tb]
> \centering
> @@ -1063,7 +1063,7 @@ Otherwise, a concurrent resize operation has already distributed this
> bucket, so line~\lnref{new_hashtbl} proceeds to the new hash table,
> line~\lnref{get_newbkt} selects the bucket corresponding to the key,
> and line~\lnref{acq_newbkt} acquires the bucket's lock.
> -\Clnref{lsp1b}{lsp1e} store the bucket pointer and
> +\Clnrefrange{lsp1b}{lsp1e} store the bucket pointer and
Thanks for catching this!
As far as I see, there is no other error in the use of \clnrefrange/\crefrange
at the moment.
To prevent similar typos in the future, I'll add a check of this pattern somewhere
in the build script.
Thanks, Akira
PS:
The email address in the From: field does not match the SOB tag.
Is this intentional?
> pointer-set index into their respective fields in the
> \co{ht_lock_state} structure, which again communicates this information to
> \co{hashtab_add()}, \co{hashtab_del()}, and \co{hashtab_unlock_mod()}.
>
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] datastruct.tex: fix some minor typos
2020-02-13 15:28 ` Akira Yokosawa
@ 2020-02-13 19:19 ` Paul E. McKenney
2020-02-14 0:46 ` Junchang Wang
2020-02-14 0:40 ` Junchang Wang
1 sibling, 1 reply; 6+ messages in thread
From: Paul E. McKenney @ 2020-02-13 19:19 UTC (permalink / raw)
To: Akira Yokosawa; +Cc: Junchang Wang, perfbook, junchangwang
On Fri, Feb 14, 2020 at 12:28:24AM +0900, Akira Yokosawa wrote:
> Hi, Junchang,
>
> On Wed, 12 Feb 2020 22:35:15 +0800, Junchang Wang wrote:
> > Signed-off-by: Junchang Wang <junchangwang@gmail.com>
> > ---
> >
> > Hi Paul,
> >
> > I'm reading the latest version of the perfbook and this patch contains fixes to
> > some typos in Section Data Structures. Hope it helps.
> >
> > Thanks,
> > --Junchang
> >
> > --
> > datastruct/datastruct.tex | 8 ++++----
> > 1 file changed, 4 insertions(+), 4 deletions(-)
> >
> > diff --git a/datastruct/datastruct.tex b/datastruct/datastruct.tex
> > index 4b62471..e21952b 100644
> > --- a/datastruct/datastruct.tex
> > +++ b/datastruct/datastruct.tex
> > @@ -700,7 +700,7 @@ Of course, it is quite possible that the differences in lookup performance
> > are affected by the differences in update rates.
> > One way to check this is to artificially throttle the update rates of
> > per-bucket locking and hazard pointers to match that of RCU.
> > -Doing so does not significantly improve the lookup performace of
> > +Doing so does not significantly improve the lookup performance of
> > per-bucket locking, nor does it close the gap between hazard pointers
> > and RCU.
> > However, removing the read-side memory barriers from hazard pointers
> > @@ -800,8 +800,8 @@ scalability, external consistency, or all of the above.
> > \section{Non-Partitionable Data Structures}
> > \label{sec:datastruct:Non-Partitionable Data Structures}
> > %
> > -\epigraph{Undertake somthing difficult, otherwise you will never grow.}
> > - {\emph{Ronald E.~Osburn}}
> > +\epigraph{Undertake something difficult, otherwise you will never grow.}
> > + {\emph{Ronald E.~Osborn}}
> >
> > \begin{figure}[tb]
> > \centering
> > @@ -1063,7 +1063,7 @@ Otherwise, a concurrent resize operation has already distributed this
> > bucket, so line~\lnref{new_hashtbl} proceeds to the new hash table,
> > line~\lnref{get_newbkt} selects the bucket corresponding to the key,
> > and line~\lnref{acq_newbkt} acquires the bucket's lock.
> > -\Clnref{lsp1b}{lsp1e} store the bucket pointer and
> > +\Clnrefrange{lsp1b}{lsp1e} store the bucket pointer and
>
> Thanks for catching this!
And from me as well! Queued and pushed, thank you!
> As far as I see, there is no other error in the use of \clnrefrange/\crefrange
> at the moment.
> To prevent similar typos in the future, I'll add a check of this pattern somewhere
> in the build script.
Looking forward to it!
> PS:
>
> The email address in the From: field does not match the SOB tag.
> Is this intentional?
I made the Signed-off-by: field match the From: field. This can be
changed if need be.
Thanx, Paul
> > pointer-set index into their respective fields in the
> > \co{ht_lock_state} structure, which again communicates this information to
> > \co{hashtab_add()}, \co{hashtab_del()}, and \co{hashtab_unlock_mod()}.
> >
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] datastruct.tex: fix some minor typos
2020-02-13 15:28 ` Akira Yokosawa
2020-02-13 19:19 ` Paul E. McKenney
@ 2020-02-14 0:40 ` Junchang Wang
2020-02-14 9:45 ` Paul E. McKenney
1 sibling, 1 reply; 6+ messages in thread
From: Junchang Wang @ 2020-02-14 0:40 UTC (permalink / raw)
To: Akira Yokosawa; +Cc: perfbook, junchangwang
On Fri, Feb 14, 2020 at 12:28:24AM +0900, Akira Yokosawa wrote:
>Hi, Junchang,
>
>On Wed, 12 Feb 2020 22:35:15 +0800, Junchang Wang wrote:
>> Signed-off-by: Junchang Wang <junchangwang@gmail.com>
>> ---
>>
>> Hi Paul,
>>
>> I'm reading the latest version of the perfbook and this patch contains fixes to
>> some typos in Section Data Structures. Hope it helps.
>>
>> Thanks,
>> --Junchang
>>
>> --
>> datastruct/datastruct.tex | 8 ++++----
>> 1 file changed, 4 insertions(+), 4 deletions(-)
>>
>> diff --git a/datastruct/datastruct.tex b/datastruct/datastruct.tex
>> index 4b62471..e21952b 100644
>> --- a/datastruct/datastruct.tex
>> +++ b/datastruct/datastruct.tex
>> @@ -700,7 +700,7 @@ Of course, it is quite possible that the differences in lookup performance
>> are affected by the differences in update rates.
>> One way to check this is to artificially throttle the update rates of
>> per-bucket locking and hazard pointers to match that of RCU.
>> -Doing so does not significantly improve the lookup performace of
>> +Doing so does not significantly improve the lookup performance of
>> per-bucket locking, nor does it close the gap between hazard pointers
>> and RCU.
>> However, removing the read-side memory barriers from hazard pointers
>> @@ -800,8 +800,8 @@ scalability, external consistency, or all of the above.
>> \section{Non-Partitionable Data Structures}
>> \label{sec:datastruct:Non-Partitionable Data Structures}
>> %
>> -\epigraph{Undertake somthing difficult, otherwise you will never grow.}
>> - {\emph{Ronald E.~Osburn}}
>> +\epigraph{Undertake something difficult, otherwise you will never grow.}
>> + {\emph{Ronald E.~Osborn}}
>>
>> \begin{figure}[tb]
>> \centering
>> @@ -1063,7 +1063,7 @@ Otherwise, a concurrent resize operation has already distributed this
>> bucket, so line~\lnref{new_hashtbl} proceeds to the new hash table,
>> line~\lnref{get_newbkt} selects the bucket corresponding to the key,
>> and line~\lnref{acq_newbkt} acquires the bucket's lock.
>> -\Clnref{lsp1b}{lsp1e} store the bucket pointer and
>> +\Clnrefrange{lsp1b}{lsp1e} store the bucket pointer and
>
>Thanks for catching this!
>
Hi Akira,
I'm very happy that it helps.
>As far as I see, there is no other error in the use of \clnrefrange/\crefrange
>at the moment.
>To prevent similar typos in the future, I'll add a check of this pattern somewhere
>in the build script.
>
Sounds great!
> Thanks, Akira
>
>PS:
>
>The email address in the From: field does not match the SOB tag.
>Is this intentional?
Oops. I decided to use the new email address (junchang2020@gmail.com)
to handle emails from mailing lists but forgot to update the SOB message.
Thanks a lot for letting me know this. I'll update my .gitconfig
accordingly and use the new SOB message in the future.
Thanks,
--Junchang
>
>> pointer-set index into their respective fields in the
>> \co{ht_lock_state} structure, which again communicates this information to
>> \co{hashtab_add()}, \co{hashtab_del()}, and \co{hashtab_unlock_mod()}.
>>
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] datastruct.tex: fix some minor typos
2020-02-13 19:19 ` Paul E. McKenney
@ 2020-02-14 0:46 ` Junchang Wang
0 siblings, 0 replies; 6+ messages in thread
From: Junchang Wang @ 2020-02-14 0:46 UTC (permalink / raw)
To: Paul E. McKenney; +Cc: Akira Yokosawa, perfbook, junchangwang
Hi Paul,
On Thu, Feb 13, 2020 at 11:19:19AM -0800, Paul E. McKenney wrote:
>On Fri, Feb 14, 2020 at 12:28:24AM +0900, Akira Yokosawa wrote:
>> Hi, Junchang,
>>
>> On Wed, 12 Feb 2020 22:35:15 +0800, Junchang Wang wrote:
>> > Signed-off-by: Junchang Wang <junchangwang@gmail.com>
>> > ---
>> >
>> > Hi Paul,
>> >
>> > I'm reading the latest version of the perfbook and this patch contains fixes to
>> > some typos in Section Data Structures. Hope it helps.
>> >
>> > Thanks,
>> > --Junchang
>> >
>> > --
>> > datastruct/datastruct.tex | 8 ++++----
>> > 1 file changed, 4 insertions(+), 4 deletions(-)
>> >
>> > diff --git a/datastruct/datastruct.tex b/datastruct/datastruct.tex
>> > index 4b62471..e21952b 100644
>> > --- a/datastruct/datastruct.tex
>> > +++ b/datastruct/datastruct.tex
>> > @@ -700,7 +700,7 @@ Of course, it is quite possible that the differences in lookup performance
>> > are affected by the differences in update rates.
>> > One way to check this is to artificially throttle the update rates of
>> > per-bucket locking and hazard pointers to match that of RCU.
>> > -Doing so does not significantly improve the lookup performace of
>> > +Doing so does not significantly improve the lookup performance of
>> > per-bucket locking, nor does it close the gap between hazard pointers
>> > and RCU.
>> > However, removing the read-side memory barriers from hazard pointers
>> > @@ -800,8 +800,8 @@ scalability, external consistency, or all of the above.
>> > \section{Non-Partitionable Data Structures}
>> > \label{sec:datastruct:Non-Partitionable Data Structures}
>> > %
>> > -\epigraph{Undertake somthing difficult, otherwise you will never grow.}
>> > - {\emph{Ronald E.~Osburn}}
>> > +\epigraph{Undertake something difficult, otherwise you will never grow.}
>> > + {\emph{Ronald E.~Osborn}}
>> >
>> > \begin{figure}[tb]
>> > \centering
>> > @@ -1063,7 +1063,7 @@ Otherwise, a concurrent resize operation has already distributed this
>> > bucket, so line~\lnref{new_hashtbl} proceeds to the new hash table,
>> > line~\lnref{get_newbkt} selects the bucket corresponding to the key,
>> > and line~\lnref{acq_newbkt} acquires the bucket's lock.
>> > -\Clnref{lsp1b}{lsp1e} store the bucket pointer and
>> > +\Clnrefrange{lsp1b}{lsp1e} store the bucket pointer and
>>
>> Thanks for catching this!
>
>And from me as well! Queued and pushed, thank you!
>
Thank you for writing this great book. I'm very happy that I can help
:-)
>> As far as I see, there is no other error in the use of \clnrefrange/\crefrange
>> at the moment.
>> To prevent similar typos in the future, I'll add a check of this pattern somewhere
>> in the build script.
>
>Looking forward to it!
>
>> PS:
>>
>> The email address in the From: field does not match the SOB tag.
>> Is this intentional?
>
>I made the Signed-off-by: field match the From: field. This can be
>changed if need be.
>
I'll use the new email address (junchang2020@gmail.com) in my
Signed-off-by message in the future. So it's not necessary for you to
change what you have done. Sorry for confusing you and Akira.
Thanks,
--Junchang
> Thanx, Paul
>
>> > pointer-set index into their respective fields in the
>> > \co{ht_lock_state} structure, which again communicates this information to
>> > \co{hashtab_add()}, \co{hashtab_del()}, and \co{hashtab_unlock_mod()}.
>> >
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] datastruct.tex: fix some minor typos
2020-02-14 0:40 ` Junchang Wang
@ 2020-02-14 9:45 ` Paul E. McKenney
0 siblings, 0 replies; 6+ messages in thread
From: Paul E. McKenney @ 2020-02-14 9:45 UTC (permalink / raw)
To: Junchang Wang; +Cc: Akira Yokosawa, perfbook, junchangwang
On Fri, Feb 14, 2020 at 08:40:34AM +0800, Junchang Wang wrote:
> On Fri, Feb 14, 2020 at 12:28:24AM +0900, Akira Yokosawa wrote:
> >Hi, Junchang,
> >
> >On Wed, 12 Feb 2020 22:35:15 +0800, Junchang Wang wrote:
> >> Signed-off-by: Junchang Wang <junchangwang@gmail.com>
> >> ---
> >>
> >> Hi Paul,
> >>
> >> I'm reading the latest version of the perfbook and this patch contains fixes to
> >> some typos in Section Data Structures. Hope it helps.
> >>
> >> Thanks,
> >> --Junchang
> >>
> >> --
> >> datastruct/datastruct.tex | 8 ++++----
> >> 1 file changed, 4 insertions(+), 4 deletions(-)
> >>
> >> diff --git a/datastruct/datastruct.tex b/datastruct/datastruct.tex
> >> index 4b62471..e21952b 100644
> >> --- a/datastruct/datastruct.tex
> >> +++ b/datastruct/datastruct.tex
> >> @@ -700,7 +700,7 @@ Of course, it is quite possible that the differences in lookup performance
> >> are affected by the differences in update rates.
> >> One way to check this is to artificially throttle the update rates of
> >> per-bucket locking and hazard pointers to match that of RCU.
> >> -Doing so does not significantly improve the lookup performace of
> >> +Doing so does not significantly improve the lookup performance of
> >> per-bucket locking, nor does it close the gap between hazard pointers
> >> and RCU.
> >> However, removing the read-side memory barriers from hazard pointers
> >> @@ -800,8 +800,8 @@ scalability, external consistency, or all of the above.
> >> \section{Non-Partitionable Data Structures}
> >> \label{sec:datastruct:Non-Partitionable Data Structures}
> >> %
> >> -\epigraph{Undertake somthing difficult, otherwise you will never grow.}
> >> - {\emph{Ronald E.~Osburn}}
> >> +\epigraph{Undertake something difficult, otherwise you will never grow.}
> >> + {\emph{Ronald E.~Osborn}}
> >>
> >> \begin{figure}[tb]
> >> \centering
> >> @@ -1063,7 +1063,7 @@ Otherwise, a concurrent resize operation has already distributed this
> >> bucket, so line~\lnref{new_hashtbl} proceeds to the new hash table,
> >> line~\lnref{get_newbkt} selects the bucket corresponding to the key,
> >> and line~\lnref{acq_newbkt} acquires the bucket's lock.
> >> -\Clnref{lsp1b}{lsp1e} store the bucket pointer and
> >> +\Clnrefrange{lsp1b}{lsp1e} store the bucket pointer and
> >
> >Thanks for catching this!
> >
>
> Hi Akira,
>
> I'm very happy that it helps.
>
> >As far as I see, there is no other error in the use of \clnrefrange/\crefrange
> >at the moment.
> >To prevent similar typos in the future, I'll add a check of this pattern somewhere
> >in the build script.
> >
>
> Sounds great!
>
> > Thanks, Akira
> >
> >PS:
> >
> >The email address in the From: field does not match the SOB tag.
> >Is this intentional?
>
> Oops. I decided to use the new email address (junchang2020@gmail.com)
> to handle emails from mailing lists but forgot to update the SOB message.
> Thanks a lot for letting me know this. I'll update my .gitconfig
> accordingly and use the new SOB message in the future.
No worries!
I recently went through email address changes myself, after all, so I
sympathize completely. ;-)
Thanx, Paul
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2020-02-14 9:45 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2020-02-12 14:35 [PATCH] datastruct.tex: fix some minor typos Junchang Wang
2020-02-13 15:28 ` Akira Yokosawa
2020-02-13 19:19 ` Paul E. McKenney
2020-02-14 0:46 ` Junchang Wang
2020-02-14 0:40 ` Junchang Wang
2020-02-14 9:45 ` 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.