* [PATCH-perfbook] Fix a little grammar mistake @ 2021-08-19 7:51 Zhouyi Zhou 2021-08-19 10:54 ` Akira Yokosawa 0 siblings, 1 reply; 12+ messages in thread From: Zhouyi Zhou @ 2021-08-19 7:51 UTC (permalink / raw) To: paulmck, perfbook, luyang.co; +Cc: 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 ^ permalink raw reply related [flat|nested] 12+ messages in thread
* Re: [PATCH-perfbook] Fix a little grammar mistake 2021-08-19 7:51 [PATCH-perfbook] Fix a little grammar mistake Zhouyi Zhou @ 2021-08-19 10:54 ` Akira Yokosawa 2021-08-19 11:39 ` Zhouyi Zhou 2021-08-19 17:29 ` Paul E. McKenney 0 siblings, 2 replies; 12+ messages in thread From: Akira Yokosawa @ 2021-08-19 10:54 UTC (permalink / raw) To: Zhouyi Zhou, paulmck, perfbook, luyang.co, 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 > ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH-perfbook] Fix a little grammar mistake 2021-08-19 10:54 ` Akira Yokosawa @ 2021-08-19 11:39 ` Zhouyi Zhou 2021-08-19 17:29 ` Paul E. McKenney 1 sibling, 0 replies; 12+ messages in thread From: Zhouyi Zhou @ 2021-08-19 11:39 UTC (permalink / raw) To: Akira Yokosawa; +Cc: paulmck, perfbook, Yang Lu 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH-perfbook] Fix a little grammar mistake 2021-08-19 10:54 ` Akira Yokosawa 2021-08-19 11:39 ` Zhouyi Zhou @ 2021-08-19 17:29 ` Paul E. McKenney 2021-08-19 21:05 ` Zhouyi Zhou 2021-08-19 23:43 ` Akira Yokosawa 1 sibling, 2 replies; 12+ messages in thread From: Paul E. McKenney @ 2021-08-19 17:29 UTC (permalink / raw) To: Akira Yokosawa; +Cc: Zhouyi Zhou, perfbook, luyang.co 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 > > ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH-perfbook] Fix a little grammar mistake 2021-08-19 17:29 ` Paul E. McKenney @ 2021-08-19 21:05 ` Zhouyi Zhou 2021-08-19 23:43 ` Akira Yokosawa 1 sibling, 0 replies; 12+ messages in thread From: Zhouyi Zhou @ 2021-08-19 21:05 UTC (permalink / raw) To: paulmck; +Cc: Akira Yokosawa, perfbook, Yang Lu 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH-perfbook] Fix a little grammar mistake 2021-08-19 17:29 ` Paul E. McKenney 2021-08-19 21:05 ` Zhouyi Zhou @ 2021-08-19 23:43 ` Akira Yokosawa 2021-08-20 2:54 ` Paul E. McKenney 1 sibling, 1 reply; 12+ messages in thread From: Akira Yokosawa @ 2021-08-19 23:43 UTC (permalink / raw) To: paulmck; +Cc: Zhouyi Zhou, perfbook, luyang.co 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 >>> ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH-perfbook] Fix a little grammar mistake 2021-08-19 23:43 ` Akira Yokosawa @ 2021-08-20 2:54 ` Paul E. McKenney 2021-08-20 10:43 ` Akira Yokosawa 0 siblings, 1 reply; 12+ messages in thread From: Paul E. McKenney @ 2021-08-20 2:54 UTC (permalink / raw) To: Akira Yokosawa; +Cc: Zhouyi Zhou, perfbook, luyang.co 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 > >>> ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH-perfbook] Fix a little grammar mistake 2021-08-20 2:54 ` Paul E. McKenney @ 2021-08-20 10:43 ` Akira Yokosawa 2021-08-20 20:04 ` Paul E. McKenney 0 siblings, 1 reply; 12+ messages in thread From: Akira Yokosawa @ 2021-08-20 10:43 UTC (permalink / raw) To: paulmck; +Cc: Zhouyi Zhou, perfbook, luyang.co 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 >>>>> ^ permalink raw reply related [flat|nested] 12+ messages in thread
* Re: [PATCH-perfbook] Fix a little grammar mistake 2021-08-20 10:43 ` Akira Yokosawa @ 2021-08-20 20:04 ` Paul E. McKenney 2021-08-20 20:21 ` Zhouyi Zhou 2021-08-20 23:30 ` Akira Yokosawa 0 siblings, 2 replies; 12+ messages in thread From: Paul E. McKenney @ 2021-08-20 20:04 UTC (permalink / raw) To: Akira Yokosawa; +Cc: Zhouyi Zhou, perfbook, luyang.co 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 ^ permalink raw reply related [flat|nested] 12+ messages in thread
* Re: [PATCH-perfbook] Fix a little grammar mistake 2021-08-20 20:04 ` Paul E. McKenney @ 2021-08-20 20:21 ` Zhouyi Zhou 2021-08-20 23:30 ` Akira Yokosawa 1 sibling, 0 replies; 12+ messages in thread From: Zhouyi Zhou @ 2021-08-20 20:21 UTC (permalink / raw) To: paulmck; +Cc: Akira Yokosawa, perfbook, Yang Lu 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH-perfbook] Fix a little grammar mistake 2021-08-20 20:04 ` Paul E. McKenney 2021-08-20 20:21 ` Zhouyi Zhou @ 2021-08-20 23:30 ` Akira Yokosawa 2021-08-20 23:53 ` Paul E. McKenney 1 sibling, 1 reply; 12+ messages in thread From: Akira Yokosawa @ 2021-08-20 23:30 UTC (permalink / raw) To: Paul E. McKenney; +Cc: Zhouyi Zhou, perfbook, luyang.co, 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 > ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH-perfbook] Fix a little grammar mistake 2021-08-20 23:30 ` Akira Yokosawa @ 2021-08-20 23:53 ` Paul E. McKenney 0 siblings, 0 replies; 12+ messages in thread From: Paul E. McKenney @ 2021-08-20 23:53 UTC (permalink / raw) To: Akira Yokosawa; +Cc: Zhouyi Zhou, perfbook, luyang.co 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 > > ^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2021-08-20 23:54 UTC | newest] Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2021-08-19 7:51 [PATCH-perfbook] Fix a little grammar mistake Zhouyi Zhou 2021-08-19 10:54 ` Akira Yokosawa 2021-08-19 11:39 ` Zhouyi Zhou 2021-08-19 17:29 ` Paul E. McKenney 2021-08-19 21:05 ` Zhouyi Zhou 2021-08-19 23:43 ` Akira Yokosawa 2021-08-20 2:54 ` Paul E. McKenney 2021-08-20 10:43 ` Akira Yokosawa 2021-08-20 20:04 ` Paul E. McKenney 2021-08-20 20:21 ` Zhouyi Zhou 2021-08-20 23:30 ` Akira Yokosawa 2021-08-20 23:53 ` 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.