[PATCH-perfbook] Fix a little grammar mistake

[PATCH-perfbook] Fix a little grammar mistake

[Zhouyi Zhou]

Hi Paul,

I think there is a little grammer mistake in answer to quick quiz 10.8,
I am not so sure because my English is not so well ;-)

Thanks
Zhouyi

Signed-off-by: Zhouyi Zhou <zhouzhouyi@gmail.com>
---
 datastruct/datastruct.tex | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/datastruct/datastruct.tex b/datastruct/datastruct.tex
index adb102d..68341f2 100644
--- a/datastruct/datastruct.tex
+++ b/datastruct/datastruct.tex
@@ -963,1 +963,1 @@ not recommended for production use.
 	In theory, it isn't any safer, and a useful exercise would be
	to run these programs on larger systems.
 	In practice, there are a lot more systems with more than 28~CPUs
-	than there are systems with more than 448 CPUs.
+	are systems with more than 448 CPUs.
 	In addition, other testing has shown that RCU read-side primitives
 	offer consistent performance and scalability up to at least 1024 CPUs.
 }\QuickQuizEnd
-- 
2.5.0

Re: [PATCH-perfbook] Fix a little grammar mistake

[Akira Yokosawa]

Hello Zhouyi,

On Thu, 19 Aug 2021 15:51:58 +0800, Zhouyi Zhou wrote:
> Hi Paul,
> 
> I think there is a little grammer mistake in answer to quick quiz 10.8,
> I am not so sure because my English is not so well ;-)
> 
> Thanks
> Zhouyi
> 
> Signed-off-by: Zhouyi Zhou <zhouzhouyi@gmail.com>
> ---
>  datastruct/datastruct.tex | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/datastruct/datastruct.tex b/datastruct/datastruct.tex
> index adb102d..68341f2 100644
> --- a/datastruct/datastruct.tex
> +++ b/datastruct/datastruct.tex
> @@ -963,1 +963,1 @@ not recommended for production use.
>  	In theory, it isn't any safer, and a useful exercise would be
> 	to run these programs on larger systems.
>  	In practice, there are a lot more systems with more than 28~CPUs
> -	than there are systems with more than 448 CPUs.

This can be parsed as follows:

    In practice, there are a lot more X than there are Y.

, where

    X: systems with more than 28~CPUs
    Y: systems with more than 448 CPUs

So there is no grammatical error here.
Three uses of "than" in a sentence might be confusing, though.

Paul might have an idea of a less-confusing sentence.

        Thanks, Akira 

> +	are systems with more than 448 CPUs.
>  	In addition, other testing has shown that RCU read-side primitives
>  	offer consistent performance and scalability up to at least 1024 CPUs.
>  }\QuickQuizEnd
> 

Re: [PATCH-perfbook] Fix a little grammar mistake

[Zhouyi Zhou]

Thanks Akira for reviewing the patch for me ;-)

On Thu, Aug 19, 2021 at 6:54 PM Akira Yokosawa <akiyks@gmail.com> wrote:
>
> Hello Zhouyi,
>
> On Thu, 19 Aug 2021 15:51:58 +0800, Zhouyi Zhou wrote:
> > Hi Paul,
> >
> > I think there is a little grammer mistake in answer to quick quiz 10.8,
> > I am not so sure because my English is not so well ;-)
> >
> > Thanks
> > Zhouyi
> >
> > Signed-off-by: Zhouyi Zhou <zhouzhouyi@gmail.com>
> > ---
> >  datastruct/datastruct.tex | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/datastruct/datastruct.tex b/datastruct/datastruct.tex
> > index adb102d..68341f2 100644
> > --- a/datastruct/datastruct.tex
> > +++ b/datastruct/datastruct.tex
> > @@ -963,1 +963,1 @@ not recommended for production use.
> >       In theory, it isn't any safer, and a useful exercise would be
> >       to run these programs on larger systems.
> >       In practice, there are a lot more systems with more than 28~CPUs
> > -     than there are systems with more than 448 CPUs.
>
> This can be parsed as follows:
>
>     In practice, there are a lot more X than there are Y.
>
> , where
>
>     X: systems with more than 28~CPUs
>     Y: systems with more than 448 CPUs
>
I learned a lot from your analysis, thanks again.

> So there is no grammatical error here.
> Three uses of "than" in a sentence might be confusing, though.
>
> Paul might have an idea of a less-confusing sentence.
>
>         Thanks, Akira
>
> > +     are systems with more than 448 CPUs.
> >       In addition, other testing has shown that RCU read-side primitives
> >       offer consistent performance and scalability up to at least 1024 CPUs.
> >  }\QuickQuizEnd
> >
Thanks
Zhouyi

Re: [PATCH-perfbook] Fix a little grammar mistake

[Paul E. McKenney]

On Thu, Aug 19, 2021 at 07:54:30PM +0900, Akira Yokosawa wrote:
> Hello Zhouyi,
> 
> On Thu, 19 Aug 2021 15:51:58 +0800, Zhouyi Zhou wrote:
> > Hi Paul,
> > 
> > I think there is a little grammer mistake in answer to quick quiz 10.8,
> > I am not so sure because my English is not so well ;-)
> > 
> > Thanks
> > Zhouyi
> > 
> > Signed-off-by: Zhouyi Zhou <zhouzhouyi@gmail.com>
> > ---
> >  datastruct/datastruct.tex | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/datastruct/datastruct.tex b/datastruct/datastruct.tex
> > index adb102d..68341f2 100644
> > --- a/datastruct/datastruct.tex
> > +++ b/datastruct/datastruct.tex
> > @@ -963,1 +963,1 @@ not recommended for production use.
> >  	In theory, it isn't any safer, and a useful exercise would be
> > 	to run these programs on larger systems.
> >  	In practice, there are a lot more systems with more than 28~CPUs
> > -	than there are systems with more than 448 CPUs.
> 
> This can be parsed as follows:
> 
>     In practice, there are a lot more X than there are Y.
> 
> , where
> 
>     X: systems with more than 28~CPUs
>     Y: systems with more than 448 CPUs
> 
> So there is no grammatical error here.
> Three uses of "than" in a sentence might be confusing, though.
> 
> Paul might have an idea of a less-confusing sentence.

Three "than"s in one sentence is a bit excessive, now that you guys
mention it.

How about this?

	In practice, there are a lot more 28-CPU systems than there are
	448-CPU systems.

I do not believe that the "more than"s are really adding much here.

Thoughts?

							Thanx, Paul

>         Thanks, Akira 
> 
> > +	are systems with more than 448 CPUs.
> >  	In addition, other testing has shown that RCU read-side primitives
> >  	offer consistent performance and scalability up to at least 1024 CPUs.
> >  }\QuickQuizEnd
> > 

Re: [PATCH-perfbook] Fix a little grammar mistake

[Zhouyi Zhou]

Thank you Paul and thank you Akira

On Fri, Aug 20, 2021 at 1:29 AM Paul E. McKenney <paulmck@kernel.org> wrote:
>
> On Thu, Aug 19, 2021 at 07:54:30PM +0900, Akira Yokosawa wrote:
> > Hello Zhouyi,
> >
> > On Thu, 19 Aug 2021 15:51:58 +0800, Zhouyi Zhou wrote:
> > > Hi Paul,
> > >
> > > I think there is a little grammer mistake in answer to quick quiz 10.8,
> > > I am not so sure because my English is not so well ;-)
> > >
> > > Thanks
> > > Zhouyi
> > >
> > > Signed-off-by: Zhouyi Zhou <zhouzhouyi@gmail.com>
> > > ---
> > >  datastruct/datastruct.tex | 2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/datastruct/datastruct.tex b/datastruct/datastruct.tex
> > > index adb102d..68341f2 100644
> > > --- a/datastruct/datastruct.tex
> > > +++ b/datastruct/datastruct.tex
> > > @@ -963,1 +963,1 @@ not recommended for production use.
> > >     In theory, it isn't any safer, and a useful exercise would be
> > >     to run these programs on larger systems.
> > >     In practice, there are a lot more systems with more than 28~CPUs
> > > -   than there are systems with more than 448 CPUs.
> >
> > This can be parsed as follows:
> >
> >     In practice, there are a lot more X than there are Y.
> >
> > , where
> >
> >     X: systems with more than 28~CPUs
> >     Y: systems with more than 448 CPUs
> >
> > So there is no grammatical error here.
> > Three uses of "than" in a sentence might be confusing, though.
> >
> > Paul might have an idea of a less-confusing sentence.
>
> Three "than"s in one sentence is a bit excessive, now that you guys
> mention it.
>
> How about this?
>
>         In practice, there are a lot more 28-CPU systems than there are
>         448-CPU systems.
The modified version reads very smoothly for me ;-)
>
> I do not believe that the "more than"s are really adding much here.
I also think so, because when I read "28-CPU system", I immediately
imagine a bundle of systems
that have some CPUs around 28, for example 24-CPU systems, 32-CPU systems ;-)
>
> Thoughts?
>
>                                                         Thanx, Paul
>
> >         Thanks, Akira
> >
> > > +   are systems with more than 448 CPUs.
> > >     In addition, other testing has shown that RCU read-side primitives
> > >     offer consistent performance and scalability up to at least 1024 CPUs.
> > >  }\QuickQuizEnd
> > >
Cheers
Zhouyi

Re: [PATCH-perfbook] Fix a little grammar mistake

[Akira Yokosawa]

On Thu, 19 Aug 2021 10:29:40 -0700, Paul E. McKenney wrote:
> On Thu, Aug 19, 2021 at 07:54:30PM +0900, Akira Yokosawa wrote:
>> Hello Zhouyi,
>>
>> On Thu, 19 Aug 2021 15:51:58 +0800, Zhouyi Zhou wrote:
>>> Hi Paul,
>>>
>>> I think there is a little grammer mistake in answer to quick quiz 10.8,
>>> I am not so sure because my English is not so well ;-)
>>>
>>> Thanks
>>> Zhouyi
>>>
>>> Signed-off-by: Zhouyi Zhou <zhouzhouyi@gmail.com>
>>> ---
>>>  datastruct/datastruct.tex | 2 +-
>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/datastruct/datastruct.tex b/datastruct/datastruct.tex
>>> index adb102d..68341f2 100644
>>> --- a/datastruct/datastruct.tex
>>> +++ b/datastruct/datastruct.tex
>>> @@ -963,1 +963,1 @@ not recommended for production use.
>>>  	In theory, it isn't any safer, and a useful exercise would be
>>> 	to run these programs on larger systems.
>>>  	In practice, there are a lot more systems with more than 28~CPUs
>>> -	than there are systems with more than 448 CPUs.
>>
>> This can be parsed as follows:
>>
>>     In practice, there are a lot more X than there are Y.
>>
>> , where
>>
>>     X: systems with more than 28~CPUs
>>     Y: systems with more than 448 CPUs
>>
>> So there is no grammatical error here.
>> Three uses of "than" in a sentence might be confusing, though.
>>
>> Paul might have an idea of a less-confusing sentence.
> 
> Three "than"s in one sentence is a bit excessive, now that you guys
> mention it.
> 
> How about this?
> 
> 	In practice, there are a lot more 28-CPU systems than there are
> 	448-CPU systems.
> 
> I do not believe that the "more than"s are really adding much here.

Well, the question part reads:

> The dangers of extrapolating from 28 CPUs to 448 CPUs was made quite
> clear in Section 10.2.3. But why should extrapolating up from 448 CPUs be
> any safer?

So, the point is "extrapolating up from 448 CPUs".
Hence you used "more than"s in the answer, didn't you?

        Thanks, Akira

> 
> Thoughts?
> 
> 							Thanx, Paul
> 
>>         Thanks, Akira 
>>
>>> +	are systems with more than 448 CPUs.
>>>  	In addition, other testing has shown that RCU read-side primitives
>>>  	offer consistent performance and scalability up to at least 1024 CPUs.
>>>  }\QuickQuizEnd
>>>

Re: [PATCH-perfbook] Fix a little grammar mistake

[Paul E. McKenney]

On Fri, Aug 20, 2021 at 08:43:13AM +0900, Akira Yokosawa wrote:
> On Thu, 19 Aug 2021 10:29:40 -0700, Paul E. McKenney wrote:
> > On Thu, Aug 19, 2021 at 07:54:30PM +0900, Akira Yokosawa wrote:
> >> Hello Zhouyi,
> >>
> >> On Thu, 19 Aug 2021 15:51:58 +0800, Zhouyi Zhou wrote:
> >>> Hi Paul,
> >>>
> >>> I think there is a little grammer mistake in answer to quick quiz 10.8,
> >>> I am not so sure because my English is not so well ;-)
> >>>
> >>> Thanks
> >>> Zhouyi
> >>>
> >>> Signed-off-by: Zhouyi Zhou <zhouzhouyi@gmail.com>
> >>> ---
> >>>  datastruct/datastruct.tex | 2 +-
> >>>  1 file changed, 1 insertion(+), 1 deletion(-)
> >>>
> >>> diff --git a/datastruct/datastruct.tex b/datastruct/datastruct.tex
> >>> index adb102d..68341f2 100644
> >>> --- a/datastruct/datastruct.tex
> >>> +++ b/datastruct/datastruct.tex
> >>> @@ -963,1 +963,1 @@ not recommended for production use.
> >>>  	In theory, it isn't any safer, and a useful exercise would be
> >>> 	to run these programs on larger systems.
> >>>  	In practice, there are a lot more systems with more than 28~CPUs
> >>> -	than there are systems with more than 448 CPUs.
> >>
> >> This can be parsed as follows:
> >>
> >>     In practice, there are a lot more X than there are Y.
> >>
> >> , where
> >>
> >>     X: systems with more than 28~CPUs
> >>     Y: systems with more than 448 CPUs
> >>
> >> So there is no grammatical error here.
> >> Three uses of "than" in a sentence might be confusing, though.
> >>
> >> Paul might have an idea of a less-confusing sentence.
> > 
> > Three "than"s in one sentence is a bit excessive, now that you guys
> > mention it.
> > 
> > How about this?
> > 
> > 	In practice, there are a lot more 28-CPU systems than there are
> > 	448-CPU systems.
> > 
> > I do not believe that the "more than"s are really adding much here.
> 
> Well, the question part reads:
> 
> > The dangers of extrapolating from 28 CPUs to 448 CPUs was made quite
> > clear in Section 10.2.3. But why should extrapolating up from 448 CPUs be
> > any safer?
> 
> So, the point is "extrapolating up from 448 CPUs".
> Hence you used "more than"s in the answer, didn't you?

Right you are, and thank you for checking this!

There are several possibilities:

	In practice, there are a lot more systems with in excess of
	28~CPUs than there are systems with in excess of 448 CPUs.

Or:

	In practice, there are only a very few systems with more than
	448 CPUs, while there is a huge number having more than 28 CPUs.

Or perhaps rework the full answer:

	In theory, it isn't any safer, and a useful exercise would be
	to run these programs on larger systems.
	In practice, there are only a very few systems with more than
	448 CPUs, in contrast to the huge number having more than 28 CPUs.
	This means that although it is dangerous to extrapolate beyond
	448 CPUs, there is very little need to do so.
	In addition, other testing has shown that RCU read-side primitives
	offer consistent performance and scalability up to at least 1024 CPUs.

Thoughts?

							Thanx, Paul

>         Thanks, Akira
> 
> > 
> > Thoughts?
> > 
> > 							Thanx, Paul
> > 
> >>         Thanks, Akira 
> >>
> >>> +	are systems with more than 448 CPUs.
> >>>  	In addition, other testing has shown that RCU read-side primitives
> >>>  	offer consistent performance and scalability up to at least 1024 CPUs.
> >>>  }\QuickQuizEnd
> >>>

Re: [PATCH-perfbook] Fix a little grammar mistake

[Akira Yokosawa]

On Thu, 19 Aug 2021 19:54:28 -0700, Paul E. McKenney wrote:
> On Fri, Aug 20, 2021 at 08:43:13AM +0900, Akira Yokosawa wrote:
>> On Thu, 19 Aug 2021 10:29:40 -0700, Paul E. McKenney wrote:
>>> On Thu, Aug 19, 2021 at 07:54:30PM +0900, Akira Yokosawa wrote:
[...]
>>>> Three uses of "than" in a sentence might be confusing, though.
>>>>
>>>> Paul might have an idea of a less-confusing sentence.
>>>
>>> Three "than"s in one sentence is a bit excessive, now that you guys
>>> mention it.
>>>
>>> How about this?
>>>
>>> 	In practice, there are a lot more 28-CPU systems than there are
>>> 	448-CPU systems.
>>>
>>> I do not believe that the "more than"s are really adding much here.
>>
>> Well, the question part reads:
>>
>>> The dangers of extrapolating from 28 CPUs to 448 CPUs was made quite
>>> clear in Section 10.2.3. But why should extrapolating up from 448 CPUs be
>>> any safer?
>>
>> So, the point is "extrapolating up from 448 CPUs".
>> Hence you used "more than"s in the answer, didn't you?
> 
> Right you are, and thank you for checking this!
> 
> There are several possibilities:
> 
> 	In practice, there are a lot more systems with in excess of
> 	28~CPUs than there are systems with in excess of 448 CPUs.
> 
> Or:
> 
> 	In practice, there are only a very few systems with more than
> 	448 CPUs, while there is a huge number having more than 28 CPUs.
> 
> Or perhaps rework the full answer:
> 
> 	In theory, it isn't any safer, and a useful exercise would be
> 	to run these programs on larger systems.
> 	In practice, there are only a very few systems with more than
> 	448 CPUs, in contrast to the huge number having more than 28 CPUs.
> 	This means that although it is dangerous to extrapolate beyond
> 	448 CPUs, there is very little need to do so.
> 	In addition, other testing has shown that RCU read-side primitives
> 	offer consistent performance and scalability up to at least 1024 CPUs.
> 
> Thoughts?

The fully reworked answer looks much clearer for me.

Besides, I'd like to suggest some changes around QQ 10.9.

As there is no mention of extrapolation before this QQ in this section,
the question of "But why should extrapolating up from 448 CPUs be any
safer?" looks kind of abrupt.
A plain yes/no question would be smoother. 

Also, the transition of discussion on Figure 10.12 (update performance)
to that on Figure 10.11 (lookup performance) in the preceding paragraphs
is not evident and I got lost for a while when I reread this section.

How about the following change?

diff --git a/datastruct/datastruct.tex b/datastruct/datastruct.tex
index adb102d4..9e386e99 100644
--- a/datastruct/datastruct.tex
+++ b/datastruct/datastruct.tex
@@ -941,6 +941,7 @@ pointers.
 Of course, all three of these implementations beat global locking.
 
 It is quite possible that the differences in lookup performance
+(\cref{fig:datastruct:Read-Side RCU-Protected Hash-Table Performance For Schroedinger's Zoo in the Presence of Updates})
 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\@.
@@ -958,7 +959,7 @@ not recommended for production use.
 	The dangers of extrapolating from 28 CPUs to 448 CPUs was
 	made quite clear in
 	\cref{sec:datastruct:Hash-Table Performance}.
-	But why should extrapolating up from 448 CPUs be any safer?
+	Would extrapolating up from 448 CPUs be any safer?
 }\QuickQuizAnswer{
 	In theory, it isn't any safer, and a useful exercise would be
 	to run these programs on larger systems.
-- 

        Thanks, Akira
> 
> 							Thanx, Paul
> 
>>         Thanks, Akira
>>
>>>
>>> Thoughts?
>>>
>>> 							Thanx, Paul
>>>
>>>>         Thanks, Akira 
>>>>
>>>>> +	are systems with more than 448 CPUs.
>>>>>  	In addition, other testing has shown that RCU read-side primitives
>>>>>  	offer consistent performance and scalability up to at least 1024 CPUs.
>>>>>  }\QuickQuizEnd
>>>>>

Re: [PATCH-perfbook] Fix a little grammar mistake

[Paul E. McKenney]

On Fri, Aug 20, 2021 at 07:43:03PM +0900, Akira Yokosawa wrote:
> On Thu, 19 Aug 2021 19:54:28 -0700, Paul E. McKenney wrote:
> > On Fri, Aug 20, 2021 at 08:43:13AM +0900, Akira Yokosawa wrote:
> >> On Thu, 19 Aug 2021 10:29:40 -0700, Paul E. McKenney wrote:
> >>> On Thu, Aug 19, 2021 at 07:54:30PM +0900, Akira Yokosawa wrote:
> [...]
> >>>> Three uses of "than" in a sentence might be confusing, though.
> >>>>
> >>>> Paul might have an idea of a less-confusing sentence.
> >>>
> >>> Three "than"s in one sentence is a bit excessive, now that you guys
> >>> mention it.
> >>>
> >>> How about this?
> >>>
> >>> 	In practice, there are a lot more 28-CPU systems than there are
> >>> 	448-CPU systems.
> >>>
> >>> I do not believe that the "more than"s are really adding much here.
> >>
> >> Well, the question part reads:
> >>
> >>> The dangers of extrapolating from 28 CPUs to 448 CPUs was made quite
> >>> clear in Section 10.2.3. But why should extrapolating up from 448 CPUs be
> >>> any safer?
> >>
> >> So, the point is "extrapolating up from 448 CPUs".
> >> Hence you used "more than"s in the answer, didn't you?
> > 
> > Right you are, and thank you for checking this!
> > 
> > There are several possibilities:
> > 
> > 	In practice, there are a lot more systems with in excess of
> > 	28~CPUs than there are systems with in excess of 448 CPUs.
> > 
> > Or:
> > 
> > 	In practice, there are only a very few systems with more than
> > 	448 CPUs, while there is a huge number having more than 28 CPUs.
> > 
> > Or perhaps rework the full answer:
> > 
> > 	In theory, it isn't any safer, and a useful exercise would be
> > 	to run these programs on larger systems.
> > 	In practice, there are only a very few systems with more than
> > 	448 CPUs, in contrast to the huge number having more than 28 CPUs.
> > 	This means that although it is dangerous to extrapolate beyond
> > 	448 CPUs, there is very little need to do so.
> > 	In addition, other testing has shown that RCU read-side primitives
> > 	offer consistent performance and scalability up to at least 1024 CPUs.
> > 
> > Thoughts?
> 
> The fully reworked answer looks much clearer for me.

OK, I started from there.

> Besides, I'd like to suggest some changes around QQ 10.9.
> 
> As there is no mention of extrapolation before this QQ in this section,
> the question of "But why should extrapolating up from 448 CPUs be any
> safer?" looks kind of abrupt.
> A plain yes/no question would be smoother. 
> 
> Also, the transition of discussion on Figure 10.12 (update performance)
> to that on Figure 10.11 (lookup performance) in the preceding paragraphs
> is not evident and I got lost for a while when I reread this section.
> 
> How about the following change?
> 
> diff --git a/datastruct/datastruct.tex b/datastruct/datastruct.tex
> index adb102d4..9e386e99 100644
> --- a/datastruct/datastruct.tex
> +++ b/datastruct/datastruct.tex
> @@ -941,6 +941,7 @@ pointers.
>  Of course, all three of these implementations beat global locking.
>  
>  It is quite possible that the differences in lookup performance
> +(\cref{fig:datastruct:Read-Side RCU-Protected Hash-Table Performance For Schroedinger's Zoo in the Presence of Updates})
>  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\@.
> @@ -958,7 +959,7 @@ not recommended for production use.
>  	The dangers of extrapolating from 28 CPUs to 448 CPUs was
>  	made quite clear in
>  	\cref{sec:datastruct:Hash-Table Performance}.
> -	But why should extrapolating up from 448 CPUs be any safer?
> +	Would extrapolating up from 448 CPUs be any safer?
>  }\QuickQuizAnswer{
>  	In theory, it isn't any safer, and a useful exercise would be
>  	to run these programs on larger systems.

I took this and also made more changes to the answer.  Does the following
seem reasonable?

							Thanx, Paul

------------------------------------------------------------------------

commit 279d626e3bcdd555031dc757441b06792ea58d38
Author: Paul E. McKenney <paulmck@kernel.org>
Date:   Fri Aug 20 13:00:56 2021 -0700

    datastruct: Expand on dangers of extrapolation
    
    This commit clarifies and expands on QQ10.9, which covers the dangers
    of extrapolation.  This commit also includes a change in wording of the
    question suggested by Akira Yokosawa.
    
    Reported-by: Zhouyi Zhou <zhouzhouyi@gmail.com>
    Signed-off-by: Paul E. McKenney <paulmck@kernel.org>

diff --git a/datastruct/datastruct.tex b/datastruct/datastruct.tex
index adb102d4..c3700332 100644
--- a/datastruct/datastruct.tex
+++ b/datastruct/datastruct.tex
@@ -955,17 +955,26 @@ usually be reliable enough for benchmarking purposes, it is absolutely
 not recommended for production use.
 
 \QuickQuiz{
-	The dangers of extrapolating from 28 CPUs to 448 CPUs was
+	The dangers of extrapolating from 28~CPUs to 448~CPUs was
 	made quite clear in
 	\cref{sec:datastruct:Hash-Table Performance}.
-	But why should extrapolating up from 448 CPUs be any safer?
+	Would extrapolating up from 448~CPUs be any safer?
 }\QuickQuizAnswer{
-	In theory, it isn't any safer, and a useful exercise would be
+	In theory, no, it isn't any safer, and a useful exercise would be
 	to run these programs on larger systems.
-	In practice, there are a lot more systems with more than 28~CPUs
-	than there are systems with more than 448 CPUs.
+	In practice, there are only a very few systems with more than
+	448~CPUs, in contrast to the huge number having more than 28~CPUs.
+	This means that although it is dangerous to extrapolate beyond
+	448~CPUs, there is very little need to do so.
+
 	In addition, other testing has shown that RCU read-side primitives
-	offer consistent performance and scalability up to at least 1024 CPUs.
+	offer consistent performance and scalability up to at least 1024~CPUs.
+	However, is useful to review
+	\cref{fig:datastruct:Read-Only RCU-Protected Hash-Table Performance For Schr\"odinger's Zoo at 448 CPUs; Varying Table Size}
+	and its associated commentary.
+	You see, unlike the 448-CPU system that provided this data,
+	the system enjoying linear scalability up to 1024~CPUs boasted
+	excellent memory bandwidth.
 }\QuickQuizEnd
 
 % @@@ Testing strategy.  Summarize hashtorture, add QQ for additional

Re: [PATCH-perfbook] Fix a little grammar mistake

[Zhouyi Zhou]

Thank you Paul and thank you Akira

The new edition is even more superior. I revised our Chinese Edition
accordingly.

Best Wishes
Zhouyi

On Sat, Aug 21, 2021 at 4:04 AM Paul E. McKenney <paulmck@kernel.org> wrote:
>
> On Fri, Aug 20, 2021 at 07:43:03PM +0900, Akira Yokosawa wrote:
> > On Thu, 19 Aug 2021 19:54:28 -0700, Paul E. McKenney wrote:
> > > On Fri, Aug 20, 2021 at 08:43:13AM +0900, Akira Yokosawa wrote:
> > >> On Thu, 19 Aug 2021 10:29:40 -0700, Paul E. McKenney wrote:
> > >>> On Thu, Aug 19, 2021 at 07:54:30PM +0900, Akira Yokosawa wrote:
> > [...]
> > >>>> Three uses of "than" in a sentence might be confusing, though.
> > >>>>
> > >>>> Paul might have an idea of a less-confusing sentence.
> > >>>
> > >>> Three "than"s in one sentence is a bit excessive, now that you guys
> > >>> mention it.
> > >>>
> > >>> How about this?
> > >>>
> > >>>   In practice, there are a lot more 28-CPU systems than there are
> > >>>   448-CPU systems.
> > >>>
> > >>> I do not believe that the "more than"s are really adding much here.
> > >>
> > >> Well, the question part reads:
> > >>
> > >>> The dangers of extrapolating from 28 CPUs to 448 CPUs was made quite
> > >>> clear in Section 10.2.3. But why should extrapolating up from 448 CPUs be
> > >>> any safer?
> > >>
> > >> So, the point is "extrapolating up from 448 CPUs".
> > >> Hence you used "more than"s in the answer, didn't you?
> > >
> > > Right you are, and thank you for checking this!
> > >
> > > There are several possibilities:
> > >
> > >     In practice, there are a lot more systems with in excess of
> > >     28~CPUs than there are systems with in excess of 448 CPUs.
> > >
> > > Or:
> > >
> > >     In practice, there are only a very few systems with more than
> > >     448 CPUs, while there is a huge number having more than 28 CPUs.
> > >
> > > Or perhaps rework the full answer:
> > >
> > >     In theory, it isn't any safer, and a useful exercise would be
> > >     to run these programs on larger systems.
> > >     In practice, there are only a very few systems with more than
> > >     448 CPUs, in contrast to the huge number having more than 28 CPUs.
> > >     This means that although it is dangerous to extrapolate beyond
> > >     448 CPUs, there is very little need to do so.
> > >     In addition, other testing has shown that RCU read-side primitives
> > >     offer consistent performance and scalability up to at least 1024 CPUs.
> > >
> > > Thoughts?
> >
> > The fully reworked answer looks much clearer for me.
>
> OK, I started from there.
>
> > Besides, I'd like to suggest some changes around QQ 10.9.
> >
> > As there is no mention of extrapolation before this QQ in this section,
> > the question of "But why should extrapolating up from 448 CPUs be any
> > safer?" looks kind of abrupt.
> > A plain yes/no question would be smoother.
> >
> > Also, the transition of discussion on Figure 10.12 (update performance)
> > to that on Figure 10.11 (lookup performance) in the preceding paragraphs
> > is not evident and I got lost for a while when I reread this section.
> >
> > How about the following change?
> >
> > diff --git a/datastruct/datastruct.tex b/datastruct/datastruct.tex
> > index adb102d4..9e386e99 100644
> > --- a/datastruct/datastruct.tex
> > +++ b/datastruct/datastruct.tex
> > @@ -941,6 +941,7 @@ pointers.
> >  Of course, all three of these implementations beat global locking.
> >
> >  It is quite possible that the differences in lookup performance
> > +(\cref{fig:datastruct:Read-Side RCU-Protected Hash-Table Performance For Schroedinger's Zoo in the Presence of Updates})
> >  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\@.
> > @@ -958,7 +959,7 @@ not recommended for production use.
> >       The dangers of extrapolating from 28 CPUs to 448 CPUs was
> >       made quite clear in
> >       \cref{sec:datastruct:Hash-Table Performance}.
> > -     But why should extrapolating up from 448 CPUs be any safer?
> > +     Would extrapolating up from 448 CPUs be any safer?
> >  }\QuickQuizAnswer{
> >       In theory, it isn't any safer, and a useful exercise would be
> >       to run these programs on larger systems.
>
> I took this and also made more changes to the answer.  Does the following
> seem reasonable?
>
>                                                         Thanx, Paul
>
> ------------------------------------------------------------------------
>
> commit 279d626e3bcdd555031dc757441b06792ea58d38
> Author: Paul E. McKenney <paulmck@kernel.org>
> Date:   Fri Aug 20 13:00:56 2021 -0700
>
>     datastruct: Expand on dangers of extrapolation
>
>     This commit clarifies and expands on QQ10.9, which covers the dangers
>     of extrapolation.  This commit also includes a change in wording of the
>     question suggested by Akira Yokosawa.
>
>     Reported-by: Zhouyi Zhou <zhouzhouyi@gmail.com>
>     Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
>
> diff --git a/datastruct/datastruct.tex b/datastruct/datastruct.tex
> index adb102d4..c3700332 100644
> --- a/datastruct/datastruct.tex
> +++ b/datastruct/datastruct.tex
> @@ -955,17 +955,26 @@ usually be reliable enough for benchmarking purposes, it is absolutely
>  not recommended for production use.
>
>  \QuickQuiz{
> -       The dangers of extrapolating from 28 CPUs to 448 CPUs was
> +       The dangers of extrapolating from 28~CPUs to 448~CPUs was
>         made quite clear in
>         \cref{sec:datastruct:Hash-Table Performance}.
> -       But why should extrapolating up from 448 CPUs be any safer?
> +       Would extrapolating up from 448~CPUs be any safer?
>  }\QuickQuizAnswer{
> -       In theory, it isn't any safer, and a useful exercise would be
> +       In theory, no, it isn't any safer, and a useful exercise would be
>         to run these programs on larger systems.
> -       In practice, there are a lot more systems with more than 28~CPUs
> -       than there are systems with more than 448 CPUs.
> +       In practice, there are only a very few systems with more than
> +       448~CPUs, in contrast to the huge number having more than 28~CPUs.
> +       This means that although it is dangerous to extrapolate beyond
> +       448~CPUs, there is very little need to do so.
> +
>         In addition, other testing has shown that RCU read-side primitives
> -       offer consistent performance and scalability up to at least 1024 CPUs.
> +       offer consistent performance and scalability up to at least 1024~CPUs.
> +       However, is useful to review
> +       \cref{fig:datastruct:Read-Only RCU-Protected Hash-Table Performance For Schr\"odinger's Zoo at 448 CPUs; Varying Table Size}
> +       and its associated commentary.
> +       You see, unlike the 448-CPU system that provided this data,
> +       the system enjoying linear scalability up to 1024~CPUs boasted
> +       excellent memory bandwidth.
>  }\QuickQuizEnd
>
>  % @@@ Testing strategy.  Summarize hashtorture, add QQ for additional

Re: [PATCH-perfbook] Fix a little grammar mistake

[Akira Yokosawa]

On Fri, 20 Aug 2021 13:04:47 -0700, Paul E. McKenney wrote:
> On Fri, Aug 20, 2021 at 07:43:03PM +0900, Akira Yokosawa wrote:
>> On Thu, 19 Aug 2021 19:54:28 -0700, Paul E. McKenney wrote:
>>> On Fri, Aug 20, 2021 at 08:43:13AM +0900, Akira Yokosawa wrote:
>>>> On Thu, 19 Aug 2021 10:29:40 -0700, Paul E. McKenney wrote:
>>>>> On Thu, Aug 19, 2021 at 07:54:30PM +0900, Akira Yokosawa wrote:
>> [...]
>>>>>> Three uses of "than" in a sentence might be confusing, though.
>>>>>>
>>>>>> Paul might have an idea of a less-confusing sentence.
>>>>>
>>>>> Three "than"s in one sentence is a bit excessive, now that you guys
>>>>> mention it.
>>>>>
>>>>> How about this?
>>>>>
>>>>> 	In practice, there are a lot more 28-CPU systems than there are
>>>>> 	448-CPU systems.
>>>>>
>>>>> I do not believe that the "more than"s are really adding much here.
>>>>
>>>> Well, the question part reads:
>>>>
>>>>> The dangers of extrapolating from 28 CPUs to 448 CPUs was made quite
>>>>> clear in Section 10.2.3. But why should extrapolating up from 448 CPUs be
>>>>> any safer?
>>>>
>>>> So, the point is "extrapolating up from 448 CPUs".
>>>> Hence you used "more than"s in the answer, didn't you?
>>>
>>> Right you are, and thank you for checking this!
>>>
>>> There are several possibilities:
>>>
>>> 	In practice, there are a lot more systems with in excess of
>>> 	28~CPUs than there are systems with in excess of 448 CPUs.
>>>
>>> Or:
>>>
>>> 	In practice, there are only a very few systems with more than
>>> 	448 CPUs, while there is a huge number having more than 28 CPUs.
>>>
>>> Or perhaps rework the full answer:
>>>
>>> 	In theory, it isn't any safer, and a useful exercise would be
>>> 	to run these programs on larger systems.
>>> 	In practice, there are only a very few systems with more than
>>> 	448 CPUs, in contrast to the huge number having more than 28 CPUs.
>>> 	This means that although it is dangerous to extrapolate beyond
>>> 	448 CPUs, there is very little need to do so.
>>> 	In addition, other testing has shown that RCU read-side primitives
>>> 	offer consistent performance and scalability up to at least 1024 CPUs.
>>>
>>> Thoughts?
>>
>> The fully reworked answer looks much clearer for me.
> 
> OK, I started from there.
> 
>> Besides, I'd like to suggest some changes around QQ 10.9.
>>
>> As there is no mention of extrapolation before this QQ in this section,
>> the question of "But why should extrapolating up from 448 CPUs be any
>> safer?" looks kind of abrupt.
>> A plain yes/no question would be smoother. 
>>
>> Also, the transition of discussion on Figure 10.12 (update performance)
>> to that on Figure 10.11 (lookup performance) in the preceding paragraphs
>> is not evident and I got lost for a while when I reread this section.
>>
>> How about the following change?
>>
>> diff --git a/datastruct/datastruct.tex b/datastruct/datastruct.tex
>> index adb102d4..9e386e99 100644
>> --- a/datastruct/datastruct.tex
>> +++ b/datastruct/datastruct.tex
>> @@ -941,6 +941,7 @@ pointers.
>>  Of course, all three of these implementations beat global locking.
>>  
>>  It is quite possible that the differences in lookup performance
>> +(\cref{fig:datastruct:Read-Side RCU-Protected Hash-Table Performance For Schroedinger's Zoo in the Presence of Updates})
>>  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\@.
>> @@ -958,7 +959,7 @@ not recommended for production use.
>>  	The dangers of extrapolating from 28 CPUs to 448 CPUs was
>>  	made quite clear in
>>  	\cref{sec:datastruct:Hash-Table Performance}.
>> -	But why should extrapolating up from 448 CPUs be any safer?
>> +	Would extrapolating up from 448 CPUs be any safer?
>>  }\QuickQuizAnswer{
>>  	In theory, it isn't any safer, and a useful exercise would be
>>  	to run these programs on larger systems.
> 
> I took this and also made more changes to the answer.  Does the following
> seem reasonable?

Looks good to me!

        Thanks, Akira

> 
> 							Thanx, Paul
> 
> ------------------------------------------------------------------------
> 
> commit 279d626e3bcdd555031dc757441b06792ea58d38
> Author: Paul E. McKenney <paulmck@kernel.org>
> Date:   Fri Aug 20 13:00:56 2021 -0700
> 
>     datastruct: Expand on dangers of extrapolation
>     
>     This commit clarifies and expands on QQ10.9, which covers the dangers
>     of extrapolation.  This commit also includes a change in wording of the
>     question suggested by Akira Yokosawa.
>     
>     Reported-by: Zhouyi Zhou <zhouzhouyi@gmail.com>
>     Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
> 
> diff --git a/datastruct/datastruct.tex b/datastruct/datastruct.tex
> index adb102d4..c3700332 100644
> --- a/datastruct/datastruct.tex
> +++ b/datastruct/datastruct.tex
> @@ -955,17 +955,26 @@ usually be reliable enough for benchmarking purposes, it is absolutely
>  not recommended for production use.
>  
>  \QuickQuiz{
> -	The dangers of extrapolating from 28 CPUs to 448 CPUs was
> +	The dangers of extrapolating from 28~CPUs to 448~CPUs was
>  	made quite clear in
>  	\cref{sec:datastruct:Hash-Table Performance}.
> -	But why should extrapolating up from 448 CPUs be any safer?
> +	Would extrapolating up from 448~CPUs be any safer?
>  }\QuickQuizAnswer{
> -	In theory, it isn't any safer, and a useful exercise would be
> +	In theory, no, it isn't any safer, and a useful exercise would be
>  	to run these programs on larger systems.
> -	In practice, there are a lot more systems with more than 28~CPUs
> -	than there are systems with more than 448 CPUs.
> +	In practice, there are only a very few systems with more than
> +	448~CPUs, in contrast to the huge number having more than 28~CPUs.
> +	This means that although it is dangerous to extrapolate beyond
> +	448~CPUs, there is very little need to do so.
> +
>  	In addition, other testing has shown that RCU read-side primitives
> -	offer consistent performance and scalability up to at least 1024 CPUs.
> +	offer consistent performance and scalability up to at least 1024~CPUs.
> +	However, is useful to review
> +	\cref{fig:datastruct:Read-Only RCU-Protected Hash-Table Performance For Schr\"odinger's Zoo at 448 CPUs; Varying Table Size}
> +	and its associated commentary.
> +	You see, unlike the 448-CPU system that provided this data,
> +	the system enjoying linear scalability up to 1024~CPUs boasted
> +	excellent memory bandwidth.
>  }\QuickQuizEnd
>  
>  % @@@ Testing strategy.  Summarize hashtorture, add QQ for additional
> 

Re: [PATCH-perfbook] Fix a little grammar mistake

[Paul E. McKenney]

On Sat, Aug 21, 2021 at 08:30:09AM +0900, Akira Yokosawa wrote:
> On Fri, 20 Aug 2021 13:04:47 -0700, Paul E. McKenney wrote:
> > On Fri, Aug 20, 2021 at 07:43:03PM +0900, Akira Yokosawa wrote:
> >> On Thu, 19 Aug 2021 19:54:28 -0700, Paul E. McKenney wrote:
> >>> On Fri, Aug 20, 2021 at 08:43:13AM +0900, Akira Yokosawa wrote:
> >>>> On Thu, 19 Aug 2021 10:29:40 -0700, Paul E. McKenney wrote:
> >>>>> On Thu, Aug 19, 2021 at 07:54:30PM +0900, Akira Yokosawa wrote:
> >> [...]
> >>>>>> Three uses of "than" in a sentence might be confusing, though.
> >>>>>>
> >>>>>> Paul might have an idea of a less-confusing sentence.
> >>>>>
> >>>>> Three "than"s in one sentence is a bit excessive, now that you guys
> >>>>> mention it.
> >>>>>
> >>>>> How about this?
> >>>>>
> >>>>> 	In practice, there are a lot more 28-CPU systems than there are
> >>>>> 	448-CPU systems.
> >>>>>
> >>>>> I do not believe that the "more than"s are really adding much here.
> >>>>
> >>>> Well, the question part reads:
> >>>>
> >>>>> The dangers of extrapolating from 28 CPUs to 448 CPUs was made quite
> >>>>> clear in Section 10.2.3. But why should extrapolating up from 448 CPUs be
> >>>>> any safer?
> >>>>
> >>>> So, the point is "extrapolating up from 448 CPUs".
> >>>> Hence you used "more than"s in the answer, didn't you?
> >>>
> >>> Right you are, and thank you for checking this!
> >>>
> >>> There are several possibilities:
> >>>
> >>> 	In practice, there are a lot more systems with in excess of
> >>> 	28~CPUs than there are systems with in excess of 448 CPUs.
> >>>
> >>> Or:
> >>>
> >>> 	In practice, there are only a very few systems with more than
> >>> 	448 CPUs, while there is a huge number having more than 28 CPUs.
> >>>
> >>> Or perhaps rework the full answer:
> >>>
> >>> 	In theory, it isn't any safer, and a useful exercise would be
> >>> 	to run these programs on larger systems.
> >>> 	In practice, there are only a very few systems with more than
> >>> 	448 CPUs, in contrast to the huge number having more than 28 CPUs.
> >>> 	This means that although it is dangerous to extrapolate beyond
> >>> 	448 CPUs, there is very little need to do so.
> >>> 	In addition, other testing has shown that RCU read-side primitives
> >>> 	offer consistent performance and scalability up to at least 1024 CPUs.
> >>>
> >>> Thoughts?
> >>
> >> The fully reworked answer looks much clearer for me.
> > 
> > OK, I started from there.
> > 
> >> Besides, I'd like to suggest some changes around QQ 10.9.
> >>
> >> As there is no mention of extrapolation before this QQ in this section,
> >> the question of "But why should extrapolating up from 448 CPUs be any
> >> safer?" looks kind of abrupt.
> >> A plain yes/no question would be smoother. 
> >>
> >> Also, the transition of discussion on Figure 10.12 (update performance)
> >> to that on Figure 10.11 (lookup performance) in the preceding paragraphs
> >> is not evident and I got lost for a while when I reread this section.
> >>
> >> How about the following change?
> >>
> >> diff --git a/datastruct/datastruct.tex b/datastruct/datastruct.tex
> >> index adb102d4..9e386e99 100644
> >> --- a/datastruct/datastruct.tex
> >> +++ b/datastruct/datastruct.tex
> >> @@ -941,6 +941,7 @@ pointers.
> >>  Of course, all three of these implementations beat global locking.
> >>  
> >>  It is quite possible that the differences in lookup performance
> >> +(\cref{fig:datastruct:Read-Side RCU-Protected Hash-Table Performance For Schroedinger's Zoo in the Presence of Updates})
> >>  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\@.
> >> @@ -958,7 +959,7 @@ not recommended for production use.
> >>  	The dangers of extrapolating from 28 CPUs to 448 CPUs was
> >>  	made quite clear in
> >>  	\cref{sec:datastruct:Hash-Table Performance}.
> >> -	But why should extrapolating up from 448 CPUs be any safer?
> >> +	Would extrapolating up from 448 CPUs be any safer?
> >>  }\QuickQuizAnswer{
> >>  	In theory, it isn't any safer, and a useful exercise would be
> >>  	to run these programs on larger systems.
> > 
> > I took this and also made more changes to the answer.  Does the following
> > seem reasonable?
> 
> Looks good to me!

Very good, I have pushed it out.  Thank you both!!!

							Thanx, Paul

>         Thanks, Akira
> 
> > 
> > 							Thanx, Paul
> > 
> > ------------------------------------------------------------------------
> > 
> > commit 279d626e3bcdd555031dc757441b06792ea58d38
> > Author: Paul E. McKenney <paulmck@kernel.org>
> > Date:   Fri Aug 20 13:00:56 2021 -0700
> > 
> >     datastruct: Expand on dangers of extrapolation
> >     
> >     This commit clarifies and expands on QQ10.9, which covers the dangers
> >     of extrapolation.  This commit also includes a change in wording of the
> >     question suggested by Akira Yokosawa.
> >     
> >     Reported-by: Zhouyi Zhou <zhouzhouyi@gmail.com>
> >     Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
> > 
> > diff --git a/datastruct/datastruct.tex b/datastruct/datastruct.tex
> > index adb102d4..c3700332 100644
> > --- a/datastruct/datastruct.tex
> > +++ b/datastruct/datastruct.tex
> > @@ -955,17 +955,26 @@ usually be reliable enough for benchmarking purposes, it is absolutely
> >  not recommended for production use.
> >  
> >  \QuickQuiz{
> > -	The dangers of extrapolating from 28 CPUs to 448 CPUs was
> > +	The dangers of extrapolating from 28~CPUs to 448~CPUs was
> >  	made quite clear in
> >  	\cref{sec:datastruct:Hash-Table Performance}.
> > -	But why should extrapolating up from 448 CPUs be any safer?
> > +	Would extrapolating up from 448~CPUs be any safer?
> >  }\QuickQuizAnswer{
> > -	In theory, it isn't any safer, and a useful exercise would be
> > +	In theory, no, it isn't any safer, and a useful exercise would be
> >  	to run these programs on larger systems.
> > -	In practice, there are a lot more systems with more than 28~CPUs
> > -	than there are systems with more than 448 CPUs.
> > +	In practice, there are only a very few systems with more than
> > +	448~CPUs, in contrast to the huge number having more than 28~CPUs.
> > +	This means that although it is dangerous to extrapolate beyond
> > +	448~CPUs, there is very little need to do so.
> > +
> >  	In addition, other testing has shown that RCU read-side primitives
> > -	offer consistent performance and scalability up to at least 1024 CPUs.
> > +	offer consistent performance and scalability up to at least 1024~CPUs.
> > +	However, is useful to review
> > +	\cref{fig:datastruct:Read-Only RCU-Protected Hash-Table Performance For Schr\"odinger's Zoo at 448 CPUs; Varying Table Size}
> > +	and its associated commentary.
> > +	You see, unlike the 448-CPU system that provided this data,
> > +	the system enjoying linear scalability up to 1024~CPUs boasted
> > +	excellent memory bandwidth.
> >  }\QuickQuizEnd
> >  
> >  % @@@ Testing strategy.  Summarize hashtorture, add QQ for additional
> >