* [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 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-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-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.