Some questions

Some questions

[Akira Yokosawa]

Hi, Paul.

The quotations recently added at the top of Chapters look really nice!
They make perfbook look more like a full-fledged publication.

However, the newly added Table 14.2 "A Variable With More Simultaneous Values"
seems like it is not complete yet.  Is that the case?

Looks like you used some custom script or something to generate the table
from a raw data that contains when each cpu sees the updates.

Do you have a plan to replace the Table with a Figure something like
Figure 14.5 "A Variable With Multiple Simultaneous Values"?

If you do, I'll refrain from touching the Table. Rather, I'd be interested
in improving the script you might be using, if any.

Another totally unrelated question is about the URL you placed in
Section C.7: "http://www.openvms.compaq.com/wizard/wiz_2637.html".
Sadly, this URL is no longer valid. Do you happen to aware of an alternative
URL still accessible today?

By looking up a Wikipedia article, I found a page at
http://h18002.www1.hp.com/alphaserver/technology/chip-docs.html,
which is "Archived technical documentation library" of Alpha
containing links to technical documentation for Alpha microprocessors
and Alpha ATX motherboards. Is there a document there which can be
referred to instead of the above mentioned URL?

                                                  Thanks, Akira

Re: Some questions

[Akira Yokosawa]

On 2016/04/27 09:53:57 -0700, Paul E. McKenney wrote:
> On Thu, Apr 28, 2016 at 12:21:48AM +0900, Akira Yokosawa wrote:
> [snip]
> 
>> However, the newly added Table 14.2 "A Variable With More Simultaneous Values"
>> seems like it is not complete yet.  Is that the case?
> 
> Please see attached for what it looks like to me.

Well, this is identical to the one I built.
So, do you intend to explicitly put numbers which show up fairly long time, and
leave other cells blank even below changes of values denoted by (n) in italics?

> 
>> Looks like you used some custom script or something to generate the table
>> from a raw data that contains when each cpu sees the updates.
>>
>> Do you have a plan to replace the Table with a Figure something like
>> Figure 14.5 "A Variable With Multiple Simultaneous Values"?
> 
> I briefly considered coloring the table cells, but got distracted.

That kind of work would be made easy if you make a script or something to
generate the latex source of the table. The problem is the script itself
might take time to make it work properly. I could be of help in that area. 

> 
> I am not sure that making a 14.5-like barchart would be all that
> readable...  But please feel free to prove me wrong.

There would be a number of very narrow bars hard to recognize.
It would also be impossible to see there are fourteen different opinions
at time 20. Yes, a table seems a better way to represent this.

> 
>> If you do, I'll refrain from touching the Table. Rather, I'd be interested
>> in improving the script you might be using, if any.
>>
>> Another totally unrelated question is about the URL you placed in
>> Section C.7: "http://www.openvms.compaq.com/wizard/wiz_2637.html".
>> Sadly, this URL is no longer valid. Do you happen to aware of an alternative
>> URL still accessible today?
> 
> This one: http://h71000.www7.hp.com/wizard/wiz_2637.html
> 
>> By looking up a Wikipedia article, I found a page at
>> http://h18002.www1.hp.com/alphaserver/technology/chip-docs.html,
>> which is "Archived technical documentation library" of Alpha
>> containing links to technical documentation for Alpha microprocessors
>> and Alpha ATX motherboards. Is there a document there which can be
>> referred to instead of the above mentioned URL?
> 
> Ah, I see...  I blew it and included the URL verbatim in the text.
> It should be replaced with \cite{Compaq01}.
> 
> Fixed, with your Reported-by!  Thank you!

Oh, you are most welcome!
                                                   Thanks, Akira
> 
> 							Thanx, Paul
> 

Re: Some questions

[Paul E. McKenney]

On Thu, Apr 28, 2016 at 07:15:05AM +0900, Akira Yokosawa wrote:
> On 2016/04/27 09:53:57 -0700, Paul E. McKenney wrote:
> > On Thu, Apr 28, 2016 at 12:21:48AM +0900, Akira Yokosawa wrote:
> > [snip]
> > 
> >> However, the newly added Table 14.2 "A Variable With More Simultaneous Values"
> >> seems like it is not complete yet.  Is that the case?
> > 
> > Please see attached for what it looks like to me.
> 
> Well, this is identical to the one I built.
> So, do you intend to explicitly put numbers which show up fairly long time, and
> leave other cells blank even below changes of values denoted by (n) in italics?

The blank cells represent cache misses.  The CPU is waiting for a read
to complete during that time.  A non-blank cell corresponds to a CPU
actually completing a read.

> >> Looks like you used some custom script or something to generate the table
> >> from a raw data that contains when each cpu sees the updates.
> >>
> >> Do you have a plan to replace the Table with a Figure something like
> >> Figure 14.5 "A Variable With Multiple Simultaneous Values"?
> > 
> > I briefly considered coloring the table cells, but got distracted.
> 
> That kind of work would be made easy if you make a script or something to
> generate the latex source of the table. The problem is the script itself
> might take time to make it work properly. I could be of help in that area. 

I probably do have something somewhere...  No guarantees of finding it...

> > I am not sure that making a 14.5-like barchart would be all that
> > readable...  But please feel free to prove me wrong.
> 
> There would be a number of very narrow bars hard to recognize.
> It would also be impossible to see there are fourteen different opinions
> at time 20. Yes, a table seems a better way to represent this.

Not sure that there is a really good way to represent this, but again,
please feel free to prove me wrong!  A nicer representation would be a
very good thing.

							Thanx, Paul

> >> If you do, I'll refrain from touching the Table. Rather, I'd be interested
> >> in improving the script you might be using, if any.
> >>
> >> Another totally unrelated question is about the URL you placed in
> >> Section C.7: "http://www.openvms.compaq.com/wizard/wiz_2637.html".
> >> Sadly, this URL is no longer valid. Do you happen to aware of an alternative
> >> URL still accessible today?
> > 
> > This one: http://h71000.www7.hp.com/wizard/wiz_2637.html
> > 
> >> By looking up a Wikipedia article, I found a page at
> >> http://h18002.www1.hp.com/alphaserver/technology/chip-docs.html,
> >> which is "Archived technical documentation library" of Alpha
> >> containing links to technical documentation for Alpha microprocessors
> >> and Alpha ATX motherboards. Is there a document there which can be
> >> referred to instead of the above mentioned URL?
> > 
> > Ah, I see...  I blew it and included the URL verbatim in the text.
> > It should be replaced with \cite{Compaq01}.
> > 
> > Fixed, with your Reported-by!  Thank you!
> 
> Oh, you are most welcome!
>                                                    Thanks, Akira
> > 
> > 							Thanx, Paul
> > 
> 

Re: Some questions

[Akira Yokosawa]

On 2016/04/27 15:50:22 -0700, Paul E. McKenney wrote:
> On Thu, Apr 28, 2016 at 07:15:05AM +0900, Akira Yokosawa wrote:
>> On 2016/04/27 09:53:57 -0700, Paul E. McKenney wrote:
>>> On Thu, Apr 28, 2016 at 12:21:48AM +0900, Akira Yokosawa wrote:
>>> [snip]
>>>
>>>> However, the newly added Table 14.2 "A Variable With More Simultaneous Values"
>>>> seems like it is not complete yet.  Is that the case?
>>>
>>> Please see attached for what it looks like to me.
>>
>> Well, this is identical to the one I built.
>> So, do you intend to explicitly put numbers which show up fairly long time, and
>> leave other cells blank even below changes of values denoted by (n) in italics?
> 
> The blank cells represent cache misses.  The CPU is waiting for a read
> to complete during that time.  A non-blank cell corresponds to a CPU
> actually completing a read.

Oh, I see. But this should be explained in the text, I think.
> 
>>>> Looks like you used some custom script or something to generate the table
>>>> from a raw data that contains when each cpu sees the updates.
>>>>
>>>> Do you have a plan to replace the Table with a Figure something like
>>>> Figure 14.5 "A Variable With Multiple Simultaneous Values"?
>>>
>>> I briefly considered coloring the table cells, but got distracted.
>>
>> That kind of work would be made easy if you make a script or something to
>> generate the latex source of the table. The problem is the script itself
>> might take time to make it work properly. I could be of help in that area. 
> 
> I probably do have something somewhere...  No guarantees of finding it...
> 
>>> I am not sure that making a 14.5-like barchart would be all that
>>> readable...  But please feel free to prove me wrong.
>>
>> There would be a number of very narrow bars hard to recognize.
>> It would also be impossible to see there are fourteen different opinions
>> at time 20. Yes, a table seems a better way to represent this.
> 
> Not sure that there is a really good way to represent this, but again,
> please feel free to prove me wrong!  A nicer representation would be a
> very good thing.
> 
> 							Thanx, Paul
> 
>>>> If you do, I'll refrain from touching the Table. Rather, I'd be interested
>>>> in improving the script you might be using, if any.
>>>>
>>>> Another totally unrelated question is about the URL you placed in
>>>> Section C.7: "http://www.openvms.compaq.com/wizard/wiz_2637.html".
>>>> Sadly, this URL is no longer valid. Do you happen to aware of an alternative
>>>> URL still accessible today?
>>>
>>> This one: http://h71000.www7.hp.com/wizard/wiz_2637.html
>>>
>>>> By looking up a Wikipedia article, I found a page at
>>>> http://h18002.www1.hp.com/alphaserver/technology/chip-docs.html,
>>>> which is "Archived technical documentation library" of Alpha
>>>> containing links to technical documentation for Alpha microprocessors
>>>> and Alpha ATX motherboards. Is there a document there which can be
>>>> referred to instead of the above mentioned URL?
>>>
>>> Ah, I see...  I blew it and included the URL verbatim in the text.
>>> It should be replaced with \cite{Compaq01}.
>>>
>>> Fixed, with your Reported-by!  Thank you!
>>
>> Oh, you are most welcome!
>>                                                    Thanks, Akira
>>>
>>> 							Thanx, Paul
>>>
>>

You might need to modify the repeated reference to the URL just before
footnote 6 in Section C.7.1

                                               Thanks, Akira

Re: Some questions

[Paul E. McKenney]

On Thu, Apr 28, 2016 at 08:01:31AM +0900, Akira Yokosawa wrote:
> On 2016/04/27 15:50:22 -0700, Paul E. McKenney wrote:
> > On Thu, Apr 28, 2016 at 07:15:05AM +0900, Akira Yokosawa wrote:
> >> On 2016/04/27 09:53:57 -0700, Paul E. McKenney wrote:
> >>> On Thu, Apr 28, 2016 at 12:21:48AM +0900, Akira Yokosawa wrote:
> >>> [snip]
> >>>
> >>>> However, the newly added Table 14.2 "A Variable With More Simultaneous Values"
> >>>> seems like it is not complete yet.  Is that the case?
> >>>
> >>> Please see attached for what it looks like to me.
> >>
> >> Well, this is identical to the one I built.
> >> So, do you intend to explicitly put numbers which show up fairly long time, and
> >> leave other cells blank even below changes of values denoted by (n) in italics?
> > 
> > The blank cells represent cache misses.  The CPU is waiting for a read
> > to complete during that time.  A non-blank cell corresponds to a CPU
> > actually completing a read.
> 
> Oh, I see. But this should be explained in the text, I think.

Good point!  I also added several other possibilities, including
interrupts and preemption.

> >>>> Looks like you used some custom script or something to generate the table
> >>>> from a raw data that contains when each cpu sees the updates.
> >>>>
> >>>> Do you have a plan to replace the Table with a Figure something like
> >>>> Figure 14.5 "A Variable With Multiple Simultaneous Values"?
> >>>
> >>> I briefly considered coloring the table cells, but got distracted.
> >>
> >> That kind of work would be made easy if you make a script or something to
> >> generate the latex source of the table. The problem is the script itself
> >> might take time to make it work properly. I could be of help in that area. 
> > 
> > I probably do have something somewhere...  No guarantees of finding it...
> > 
> >>> I am not sure that making a 14.5-like barchart would be all that
> >>> readable...  But please feel free to prove me wrong.
> >>
> >> There would be a number of very narrow bars hard to recognize.
> >> It would also be impossible to see there are fourteen different opinions
> >> at time 20. Yes, a table seems a better way to represent this.
> > 
> > Not sure that there is a really good way to represent this, but again,
> > please feel free to prove me wrong!  A nicer representation would be a
> > very good thing.
> > 
> > 							Thanx, Paul
> > 
> >>>> If you do, I'll refrain from touching the Table. Rather, I'd be interested
> >>>> in improving the script you might be using, if any.
> >>>>
> >>>> Another totally unrelated question is about the URL you placed in
> >>>> Section C.7: "http://www.openvms.compaq.com/wizard/wiz_2637.html".
> >>>> Sadly, this URL is no longer valid. Do you happen to aware of an alternative
> >>>> URL still accessible today?
> >>>
> >>> This one: http://h71000.www7.hp.com/wizard/wiz_2637.html
> >>>
> >>>> By looking up a Wikipedia article, I found a page at
> >>>> http://h18002.www1.hp.com/alphaserver/technology/chip-docs.html,
> >>>> which is "Archived technical documentation library" of Alpha
> >>>> containing links to technical documentation for Alpha microprocessors
> >>>> and Alpha ATX motherboards. Is there a document there which can be
> >>>> referred to instead of the above mentioned URL?
> >>>
> >>> Ah, I see...  I blew it and included the URL verbatim in the text.
> >>> It should be replaced with \cite{Compaq01}.
> >>>
> >>> Fixed, with your Reported-by!  Thank you!
> >>
> >> Oh, you are most welcome!
> >>                                                    Thanks, Akira
> >>>
> >>> 							Thanx, Paul
> >>>
> >>
> 
> You might need to modify the repeated reference to the URL just before
> footnote 6 in Section C.7.1

Good catch!  I put the citation here as well.

							Thanx, Paul

Re: Some questions

[Akira Yokosawa]

On 2016/04/27 16:28:07 -0700, Paul E. McKenney wrote:
> On Thu, Apr 28, 2016 at 08:01:31AM +0900, Akira Yokosawa wrote:
>> On 2016/04/27 15:50:22 -0700, Paul E. McKenney wrote:
>>> On Thu, Apr 28, 2016 at 07:15:05AM +0900, Akira Yokosawa wrote:
>>>> On 2016/04/27 09:53:57 -0700, Paul E. McKenney wrote:
[snip.
>>>>> Please see attached for what it looks like to me.
>>>>
>>>> Well, this is identical to the one I built.
>>>> So, do you intend to explicitly put numbers which show up fairly long time, and
>>>> leave other cells blank even below changes of values denoted by (n) in italics?
>>>
>>> The blank cells represent cache misses.  The CPU is waiting for a read
>>> to complete during that time.  A non-blank cell corresponds to a CPU
>>> actually completing a read.
>>
>> Oh, I see. But this should be explained in the text, I think.
> 
> Good point!  I also added several other possibilities, including
> interrupts and preemption.
> 

So, I have a few questions regarding to the added explanation of blank cells.

According to the text, trace data used to create the table are said to be 
obtained by a program that contains the code fragment shown in Figure 14.4.
The loop in the code fragment will exit once it sees state.variable != mycpu.
That means the actual program you used has an outer loop to record the
changes of state.valuable for each cpu in the system, I suppose.
Am I guessing right?

If I am, (n)'s in the table denoting modification of variables must be
entries in the trace data which were output from the outer loop, I think.

However, in the table, there are a number of cases where (n)'s are followed
by blanks just below itself. Does this mean fetched state.variables stay in
the cache very briefly, but are (almost immediately) invalidated by a cache
coherence mechanism? I can see interrupts and preemption would also cause the
trace output to be suspended for a while.

I'm not sure I have made out what the table means thus far, but am I seeing
something close enough to what you intend the table to represent?

                                                     Thanks, Akira

Re: Some questions

[Paul E. McKenney]

On Fri, Apr 29, 2016 at 12:39:09AM +0900, Akira Yokosawa wrote:
> On 2016/04/27 16:28:07 -0700, Paul E. McKenney wrote:
> > On Thu, Apr 28, 2016 at 08:01:31AM +0900, Akira Yokosawa wrote:
> >> On 2016/04/27 15:50:22 -0700, Paul E. McKenney wrote:
> >>> On Thu, Apr 28, 2016 at 07:15:05AM +0900, Akira Yokosawa wrote:
> >>>> On 2016/04/27 09:53:57 -0700, Paul E. McKenney wrote:
> [snip.
> >>>>> Please see attached for what it looks like to me.
> >>>>
> >>>> Well, this is identical to the one I built.
> >>>> So, do you intend to explicitly put numbers which show up fairly long time, and
> >>>> leave other cells blank even below changes of values denoted by (n) in italics?
> >>>
> >>> The blank cells represent cache misses.  The CPU is waiting for a read
> >>> to complete during that time.  A non-blank cell corresponds to a CPU
> >>> actually completing a read.
> >>
> >> Oh, I see. But this should be explained in the text, I think.
> > 
> > Good point!  I also added several other possibilities, including
> > interrupts and preemption.
> > 
> 
> So, I have a few questions regarding to the added explanation of blank cells.
> 
> According to the text, trace data used to create the table are said to be 
> obtained by a program that contains the code fragment shown in Figure 14.4.
> The loop in the code fragment will exit once it sees state.variable != mycpu.
> That means the actual program you used has an outer loop to record the
> changes of state.valuable for each cpu in the system, I suppose.
> Am I guessing right?

IIRC, the program just stuffed timestamps and values into a set of per-CPU
big arrays, then printed them out.  A script took these values as input,
and compacted identical state.

> If I am, (n)'s in the table denoting modification of variables must be
> entries in the trace data which were output from the outer loop, I think.

The (n)'s mark changes in value for a given CPU.

> However, in the table, there are a number of cases where (n)'s are followed
> by blanks just below itself. Does this mean fetched state.variables stay in
> the cache very briefly, but are (almost immediately) invalidated by a cache
> coherence mechanism? I can see interrupts and preemption would also cause the
> trace output to be suspended for a while.

It marks places where a given CPU saw a value momentarily.  As you say,
this could be due to cache invalidation, interrupts, preemption, etc.

> I'm not sure I have made out what the table means thus far, but am I seeing
> something close enough to what you intend the table to represent?

The main point is that different CPUs can disagree on the value of a given
variable at a given point in time.  The following diagram shows that
this disagreement is nevertheless bounded, in that all CPUs must agree
on the ordering of values for that variable.

							Thanx, Paul

Re: Some questions

[Akira Yokosawa]

On 2016/04/29 1:28, Paul E. McKenney wrote:
> On Fri, Apr 29, 2016 at 12:39:09AM +0900, Akira Yokosawa wrote:
>> On 2016/04/27 16:28:07 -0700, Paul E. McKenney wrote:
>>> On Thu, Apr 28, 2016 at 08:01:31AM +0900, Akira Yokosawa wrote:
>>>> On 2016/04/27 15:50:22 -0700, Paul E. McKenney wrote:
>>>>> On Thu, Apr 28, 2016 at 07:15:05AM +0900, Akira Yokosawa wrote:
>>>>>> On 2016/04/27 09:53:57 -0700, Paul E. McKenney wrote:
>> [snip.
>>>>>>> Please see attached for what it looks like to me.
>>>>>>
>>>>>> Well, this is identical to the one I built.
>>>>>> So, do you intend to explicitly put numbers which show up fairly long time, and
>>>>>> leave other cells blank even below changes of values denoted by (n) in italics?
>>>>>
>>>>> The blank cells represent cache misses.  The CPU is waiting for a read
>>>>> to complete during that time.  A non-blank cell corresponds to a CPU
>>>>> actually completing a read.
>>>>
>>>> Oh, I see. But this should be explained in the text, I think.
>>>
>>> Good point!  I also added several other possibilities, including
>>> interrupts and preemption.
>>>
>>
>> So, I have a few questions regarding to the added explanation of blank cells.
>>
>> According to the text, trace data used to create the table are said to be 
>> obtained by a program that contains the code fragment shown in Figure 14.4.
>> The loop in the code fragment will exit once it sees state.variable != mycpu.
>> That means the actual program you used has an outer loop to record the
>> changes of state.valuable for each cpu in the system, I suppose.
>> Am I guessing right?
> 
> IIRC, the program just stuffed timestamps and values into a set of per-CPU
> big arrays, then printed them out.  A script took these values as input,
> and compacted identical state.
> 
>> If I am, (n)'s in the table denoting modification of variables must be
>> entries in the trace data which were output from the outer loop, I think.
> 
> The (n)'s mark changes in value for a given CPU.
> 
>> However, in the table, there are a number of cases where (n)'s are followed
>> by blanks just below itself. Does this mean fetched state.variables stay in
>> the cache very briefly, but are (almost immediately) invalidated by a cache
>> coherence mechanism? I can see interrupts and preemption would also cause the
>> trace output to be suspended for a while.
> 
> It marks places where a given CPU saw a value momentarily.  As you say,
> this could be due to cache invalidation, interrupts, preemption, etc.
> 
>> I'm not sure I have made out what the table means thus far, but am I seeing
>> something close enough to what you intend the table to represent?
> 
> The main point is that different CPUs can disagree on the value of a given
> variable at a given point in time.  The following diagram shows that
> this disagreement is nevertheless bounded, in that all CPUs must agree
> on the ordering of values for that variable.

Yes, of course that's the main point.
I should have asked in a different way.

There should be the same kind of situations in Figure 14.5.
But you didn't depict them in the figure.

Why did you put the blank cells in the table in the first place?

I'm a little bit distracted by those blank cells, and began questioning
about them.

Isn't it enough to just do the same way in Table 14.2 as in Figure 14.5?

Or, could the blank cell situation be explained in the form of an answer
of a quick quiz?  It would be much easier for me to grasp the main point
of this section "Variables Can Have More Than One Value" while reading the
body of the text.

Thoughts?

                                                   Thanks, Akira

> 
> 							Thanx, Paul
> 
> 

Re: Some questions

[Akira Yokosawa]

[-- Attachment #1: Type: text/plain, Size: 4367 bytes --]

On 2016/04/29 8:05, Akira Yokosawa wrote:
> On 2016/04/29 1:28, Paul E. McKenney wrote:
>> On Fri, Apr 29, 2016 at 12:39:09AM +0900, Akira Yokosawa wrote:
>>> On 2016/04/27 16:28:07 -0700, Paul E. McKenney wrote:
>>>> On Thu, Apr 28, 2016 at 08:01:31AM +0900, Akira Yokosawa wrote:
>>>>> On 2016/04/27 15:50:22 -0700, Paul E. McKenney wrote:
>>>>>> On Thu, Apr 28, 2016 at 07:15:05AM +0900, Akira Yokosawa wrote:
>>>>>>> On 2016/04/27 09:53:57 -0700, Paul E. McKenney wrote:
>>> [snip.
>>>>>>>> Please see attached for what it looks like to me.
>>>>>>>
>>>>>>> Well, this is identical to the one I built.
>>>>>>> So, do you intend to explicitly put numbers which show up fairly long time, and
>>>>>>> leave other cells blank even below changes of values denoted by (n) in italics?
>>>>>>
>>>>>> The blank cells represent cache misses.  The CPU is waiting for a read
>>>>>> to complete during that time.  A non-blank cell corresponds to a CPU
>>>>>> actually completing a read.
>>>>>
>>>>> Oh, I see. But this should be explained in the text, I think.
>>>>
>>>> Good point!  I also added several other possibilities, including
>>>> interrupts and preemption.
>>>>
>>>
>>> So, I have a few questions regarding to the added explanation of blank cells.
>>>
>>> According to the text, trace data used to create the table are said to be 
>>> obtained by a program that contains the code fragment shown in Figure 14.4.
>>> The loop in the code fragment will exit once it sees state.variable != mycpu.
>>> That means the actual program you used has an outer loop to record the
>>> changes of state.valuable for each cpu in the system, I suppose.
>>> Am I guessing right?
>>
>> IIRC, the program just stuffed timestamps and values into a set of per-CPU
>> big arrays, then printed them out.  A script took these values as input,
>> and compacted identical state.
>>
>>> If I am, (n)'s in the table denoting modification of variables must be
>>> entries in the trace data which were output from the outer loop, I think.
>>
>> The (n)'s mark changes in value for a given CPU.
>>
>>> However, in the table, there are a number of cases where (n)'s are followed
>>> by blanks just below itself. Does this mean fetched state.variables stay in
>>> the cache very briefly, but are (almost immediately) invalidated by a cache
>>> coherence mechanism? I can see interrupts and preemption would also cause the
>>> trace output to be suspended for a while.
>>
>> It marks places where a given CPU saw a value momentarily.  As you say,
>> this could be due to cache invalidation, interrupts, preemption, etc.
>>
>>> I'm not sure I have made out what the table means thus far, but am I seeing
>>> something close enough to what you intend the table to represent?
>>
>> The main point is that different CPUs can disagree on the value of a given
>> variable at a given point in time.  The following diagram shows that
>> this disagreement is nevertheless bounded, in that all CPUs must agree
>> on the ordering of values for that variable.
> 
> Yes, of course that's the main point.
> I should have asked in a different way.
> 
> There should be the same kind of situations in Figure 14.5.
> But you didn't depict them in the figure.
> 
> Why did you put the blank cells in the table in the first place?
> 
> I'm a little bit distracted by those blank cells, and began questioning
> about them.
> 
> Isn't it enough to just do the same way in Table 14.2 as in Figure 14.5?
> 
> Or, could the blank cell situation be explained in the form of an answer
> of a quick quiz?  It would be much easier for me to grasp the main point
> of this section "Variables Can Have More Than One Value" while reading the
> body of the text.
> 
> Thoughts?
> 
>                                                    Thanks, Akira
> 
>>
>> 							Thanx, Paul
>>
>>
> 

So I drew 2 figures based on Table 14.2.
No, I didn't actually drew them but wrote a rough program to generate .fig
format files from the value changes of each CPU extracted from Table 14.2.
I ignored the blank cells in the table just as in Figure 4.5.
Appended is a tar ball of two files.
out.fig is the overall diagram, and out-2.fig is a zoomed in view of
the beginning part.
I think they can provide a fairly interesting view of what's going on.

Please give a look at them.

                                                    Thanks, Akira

[-- Attachment #2: fig.tar.gz --]
[-- Type: application/gzip, Size: 2368 bytes --]

Re: Some questions

[Paul E. McKenney]

On Sat, Apr 30, 2016 at 01:00:29AM +0900, Akira Yokosawa wrote:
> On 2016/04/29 8:05, Akira Yokosawa wrote:
> > On 2016/04/29 1:28, Paul E. McKenney wrote:
> >> On Fri, Apr 29, 2016 at 12:39:09AM +0900, Akira Yokosawa wrote:
> >>> On 2016/04/27 16:28:07 -0700, Paul E. McKenney wrote:
> >>>> On Thu, Apr 28, 2016 at 08:01:31AM +0900, Akira Yokosawa wrote:
> >>>>> On 2016/04/27 15:50:22 -0700, Paul E. McKenney wrote:
> >>>>>> On Thu, Apr 28, 2016 at 07:15:05AM +0900, Akira Yokosawa wrote:
> >>>>>>> On 2016/04/27 09:53:57 -0700, Paul E. McKenney wrote:
> >>> [snip.
> >>>>>>>> Please see attached for what it looks like to me.
> >>>>>>>
> >>>>>>> Well, this is identical to the one I built.
> >>>>>>> So, do you intend to explicitly put numbers which show up fairly long time, and
> >>>>>>> leave other cells blank even below changes of values denoted by (n) in italics?
> >>>>>>
> >>>>>> The blank cells represent cache misses.  The CPU is waiting for a read
> >>>>>> to complete during that time.  A non-blank cell corresponds to a CPU
> >>>>>> actually completing a read.
> >>>>>
> >>>>> Oh, I see. But this should be explained in the text, I think.
> >>>>
> >>>> Good point!  I also added several other possibilities, including
> >>>> interrupts and preemption.
> >>>>
> >>>
> >>> So, I have a few questions regarding to the added explanation of blank cells.
> >>>
> >>> According to the text, trace data used to create the table are said to be 
> >>> obtained by a program that contains the code fragment shown in Figure 14.4.
> >>> The loop in the code fragment will exit once it sees state.variable != mycpu.
> >>> That means the actual program you used has an outer loop to record the
> >>> changes of state.valuable for each cpu in the system, I suppose.
> >>> Am I guessing right?
> >>
> >> IIRC, the program just stuffed timestamps and values into a set of per-CPU
> >> big arrays, then printed them out.  A script took these values as input,
> >> and compacted identical state.
> >>
> >>> If I am, (n)'s in the table denoting modification of variables must be
> >>> entries in the trace data which were output from the outer loop, I think.
> >>
> >> The (n)'s mark changes in value for a given CPU.
> >>
> >>> However, in the table, there are a number of cases where (n)'s are followed
> >>> by blanks just below itself. Does this mean fetched state.variables stay in
> >>> the cache very briefly, but are (almost immediately) invalidated by a cache
> >>> coherence mechanism? I can see interrupts and preemption would also cause the
> >>> trace output to be suspended for a while.
> >>
> >> It marks places where a given CPU saw a value momentarily.  As you say,
> >> this could be due to cache invalidation, interrupts, preemption, etc.
> >>
> >>> I'm not sure I have made out what the table means thus far, but am I seeing
> >>> something close enough to what you intend the table to represent?
> >>
> >> The main point is that different CPUs can disagree on the value of a given
> >> variable at a given point in time.  The following diagram shows that
> >> this disagreement is nevertheless bounded, in that all CPUs must agree
> >> on the ordering of values for that variable.
> > 
> > Yes, of course that's the main point.
> > I should have asked in a different way.
> > 
> > There should be the same kind of situations in Figure 14.5.
> > But you didn't depict them in the figure.
> > 
> > Why did you put the blank cells in the table in the first place?
> > 
> > I'm a little bit distracted by those blank cells, and began questioning
> > about them.
> > 
> > Isn't it enough to just do the same way in Table 14.2 as in Figure 14.5?
> > 
> > Or, could the blank cell situation be explained in the form of an answer
> > of a quick quiz?  It would be much easier for me to grasp the main point
> > of this section "Variables Can Have More Than One Value" while reading the
> > body of the text.
> > 
> > Thoughts?
> > 
> >                                                    Thanks, Akira
> > 
> >>
> >> 							Thanx, Paul
> >>
> >>
> > 
> 
> So I drew 2 figures based on Table 14.2.
> No, I didn't actually drew them but wrote a rough program to generate .fig
> format files from the value changes of each CPU extracted from Table 14.2.
> I ignored the blank cells in the table just as in Figure 4.5.
> Appended is a tar ball of two files.
> out.fig is the overall diagram, and out-2.fig is a zoomed in view of
> the beginning part.
> I think they can provide a fairly interesting view of what's going on.
> 
> Please give a look at them.

Not bad, actually!

The solid black areas need to be hatched or grey, otherwise it is a bit
hard on printers.  The colored areas look OK to me, though that does
not necessarily count for much.  ;-)

Would you like to send a patch replacing the table with these diagrams
and updating the text appropriately?

						Thanx, Paul

Re: Some questions

[Akira Yokosawa]

On 2016/04/30 2:15, Paul E. McKenney wrote:
> On Sat, Apr 30, 2016 at 01:00:29AM +0900, Akira Yokosawa wrote:
>> On 2016/04/29 8:05, Akira Yokosawa wrote:
>>> On 2016/04/29 1:28, Paul E. McKenney wrote:
>>>> On Fri, Apr 29, 2016 at 12:39:09AM +0900, Akira Yokosawa wrote:
>>>>> On 2016/04/27 16:28:07 -0700, Paul E. McKenney wrote:
>>>>>> On Thu, Apr 28, 2016 at 08:01:31AM +0900, Akira Yokosawa wrote:
>>>>>>> On 2016/04/27 15:50:22 -0700, Paul E. McKenney wrote:
>>>>>>>> On Thu, Apr 28, 2016 at 07:15:05AM +0900, Akira Yokosawa wrote:
>>>>>>>>> On 2016/04/27 09:53:57 -0700, Paul E. McKenney wrote:
>>>>> [snip.
>>>>>>>>>> Please see attached for what it looks like to me.
>>>>>>>>>
>>>>>>>>> Well, this is identical to the one I built.
>>>>>>>>> So, do you intend to explicitly put numbers which show up fairly long time, and
>>>>>>>>> leave other cells blank even below changes of values denoted by (n) in italics?
>>>>>>>>
>>>>>>>> The blank cells represent cache misses.  The CPU is waiting for a read
>>>>>>>> to complete during that time.  A non-blank cell corresponds to a CPU
>>>>>>>> actually completing a read.
>>>>>>>
>>>>>>> Oh, I see. But this should be explained in the text, I think.
>>>>>>
>>>>>> Good point!  I also added several other possibilities, including
>>>>>> interrupts and preemption.
>>>>>>
>>>>>
>>>>> So, I have a few questions regarding to the added explanation of blank cells.
>>>>>
>>>>> According to the text, trace data used to create the table are said to be 
>>>>> obtained by a program that contains the code fragment shown in Figure 14.4.
>>>>> The loop in the code fragment will exit once it sees state.variable != mycpu.
>>>>> That means the actual program you used has an outer loop to record the
>>>>> changes of state.valuable for each cpu in the system, I suppose.
>>>>> Am I guessing right?
>>>>
>>>> IIRC, the program just stuffed timestamps and values into a set of per-CPU
>>>> big arrays, then printed them out.  A script took these values as input,
>>>> and compacted identical state.
>>>>
>>>>> If I am, (n)'s in the table denoting modification of variables must be
>>>>> entries in the trace data which were output from the outer loop, I think.
>>>>
>>>> The (n)'s mark changes in value for a given CPU.
>>>>
>>>>> However, in the table, there are a number of cases where (n)'s are followed
>>>>> by blanks just below itself. Does this mean fetched state.variables stay in
>>>>> the cache very briefly, but are (almost immediately) invalidated by a cache
>>>>> coherence mechanism? I can see interrupts and preemption would also cause the
>>>>> trace output to be suspended for a while.
>>>>
>>>> It marks places where a given CPU saw a value momentarily.  As you say,
>>>> this could be due to cache invalidation, interrupts, preemption, etc.
>>>>
>>>>> I'm not sure I have made out what the table means thus far, but am I seeing
>>>>> something close enough to what you intend the table to represent?
>>>>
>>>> The main point is that different CPUs can disagree on the value of a given
>>>> variable at a given point in time.  The following diagram shows that
>>>> this disagreement is nevertheless bounded, in that all CPUs must agree
>>>> on the ordering of values for that variable.
>>>
>>> Yes, of course that's the main point.
>>> I should have asked in a different way.
>>>
>>> There should be the same kind of situations in Figure 14.5.
>>> But you didn't depict them in the figure.
>>>
>>> Why did you put the blank cells in the table in the first place?
>>>
>>> I'm a little bit distracted by those blank cells, and began questioning
>>> about them.
>>>
>>> Isn't it enough to just do the same way in Table 14.2 as in Figure 14.5?
>>>
>>> Or, could the blank cell situation be explained in the form of an answer
>>> of a quick quiz?  It would be much easier for me to grasp the main point
>>> of this section "Variables Can Have More Than One Value" while reading the
>>> body of the text.
>>>
>>> Thoughts?
>>>
>>>                                                    Thanks, Akira
>>>
>>>>
>>>> 							Thanx, Paul
>>>>
>>>>
>>>
>>
>> So I drew 2 figures based on Table 14.2.
>> No, I didn't actually drew them but wrote a rough program to generate .fig
>> format files from the value changes of each CPU extracted from Table 14.2.
>> I ignored the blank cells in the table just as in Figure 4.5.
>> Appended is a tar ball of two files.
>> out.fig is the overall diagram, and out-2.fig is a zoomed in view of
>> the beginning part.
>> I think they can provide a fairly interesting view of what's going on.
>>
>> Please give a look at them.
> 
> Not bad, actually!
> 
> The solid black areas need to be hatched or grey, otherwise it is a bit
> hard on printers.  The colored areas look OK to me, though that does
> not necessarily count for much.  ;-)

I'll see what I can.

> 
> Would you like to send a patch replacing the table with these diagrams
> and updating the text appropriately?

I'd love to!
And may I remove the explanation of the "white cell situation" for now?
Or do you want to keep those info in another set of diagrams which would
depict the unresponsive periods in some way (translucent hatch or something)
so that you could refer to them in a quick quiz you might come up with
some day? 

                                                  Thanks, Akira
> 
> 						Thanx, Paul
> 
> 

Re: Some questions

[Paul E. McKenney]

On Sat, Apr 30, 2016 at 07:06:39AM +0900, Akira Yokosawa wrote:
> On 2016/04/30 2:15, Paul E. McKenney wrote:
> > On Sat, Apr 30, 2016 at 01:00:29AM +0900, Akira Yokosawa wrote:
> >> On 2016/04/29 8:05, Akira Yokosawa wrote:
> >>> On 2016/04/29 1:28, Paul E. McKenney wrote:
> >>>> On Fri, Apr 29, 2016 at 12:39:09AM +0900, Akira Yokosawa wrote:
> >>>>> On 2016/04/27 16:28:07 -0700, Paul E. McKenney wrote:
> >>>>>> On Thu, Apr 28, 2016 at 08:01:31AM +0900, Akira Yokosawa wrote:
> >>>>>>> On 2016/04/27 15:50:22 -0700, Paul E. McKenney wrote:
> >>>>>>>> On Thu, Apr 28, 2016 at 07:15:05AM +0900, Akira Yokosawa wrote:
> >>>>>>>>> On 2016/04/27 09:53:57 -0700, Paul E. McKenney wrote:
> >>>>> [snip.
> >>>>>>>>>> Please see attached for what it looks like to me.
> >>>>>>>>>
> >>>>>>>>> Well, this is identical to the one I built.
> >>>>>>>>> So, do you intend to explicitly put numbers which show up fairly long time, and
> >>>>>>>>> leave other cells blank even below changes of values denoted by (n) in italics?
> >>>>>>>>
> >>>>>>>> The blank cells represent cache misses.  The CPU is waiting for a read
> >>>>>>>> to complete during that time.  A non-blank cell corresponds to a CPU
> >>>>>>>> actually completing a read.
> >>>>>>>
> >>>>>>> Oh, I see. But this should be explained in the text, I think.
> >>>>>>
> >>>>>> Good point!  I also added several other possibilities, including
> >>>>>> interrupts and preemption.
> >>>>>>
> >>>>>
> >>>>> So, I have a few questions regarding to the added explanation of blank cells.
> >>>>>
> >>>>> According to the text, trace data used to create the table are said to be 
> >>>>> obtained by a program that contains the code fragment shown in Figure 14.4.
> >>>>> The loop in the code fragment will exit once it sees state.variable != mycpu.
> >>>>> That means the actual program you used has an outer loop to record the
> >>>>> changes of state.valuable for each cpu in the system, I suppose.
> >>>>> Am I guessing right?
> >>>>
> >>>> IIRC, the program just stuffed timestamps and values into a set of per-CPU
> >>>> big arrays, then printed them out.  A script took these values as input,
> >>>> and compacted identical state.
> >>>>
> >>>>> If I am, (n)'s in the table denoting modification of variables must be
> >>>>> entries in the trace data which were output from the outer loop, I think.
> >>>>
> >>>> The (n)'s mark changes in value for a given CPU.
> >>>>
> >>>>> However, in the table, there are a number of cases where (n)'s are followed
> >>>>> by blanks just below itself. Does this mean fetched state.variables stay in
> >>>>> the cache very briefly, but are (almost immediately) invalidated by a cache
> >>>>> coherence mechanism? I can see interrupts and preemption would also cause the
> >>>>> trace output to be suspended for a while.
> >>>>
> >>>> It marks places where a given CPU saw a value momentarily.  As you say,
> >>>> this could be due to cache invalidation, interrupts, preemption, etc.
> >>>>
> >>>>> I'm not sure I have made out what the table means thus far, but am I seeing
> >>>>> something close enough to what you intend the table to represent?
> >>>>
> >>>> The main point is that different CPUs can disagree on the value of a given
> >>>> variable at a given point in time.  The following diagram shows that
> >>>> this disagreement is nevertheless bounded, in that all CPUs must agree
> >>>> on the ordering of values for that variable.
> >>>
> >>> Yes, of course that's the main point.
> >>> I should have asked in a different way.
> >>>
> >>> There should be the same kind of situations in Figure 14.5.
> >>> But you didn't depict them in the figure.
> >>>
> >>> Why did you put the blank cells in the table in the first place?
> >>>
> >>> I'm a little bit distracted by those blank cells, and began questioning
> >>> about them.
> >>>
> >>> Isn't it enough to just do the same way in Table 14.2 as in Figure 14.5?
> >>>
> >>> Or, could the blank cell situation be explained in the form of an answer
> >>> of a quick quiz?  It would be much easier for me to grasp the main point
> >>> of this section "Variables Can Have More Than One Value" while reading the
> >>> body of the text.
> >>>
> >>> Thoughts?
> >>>
> >>>                                                    Thanks, Akira
> >>>
> >>>>
> >>>> 							Thanx, Paul
> >>>>
> >>>>
> >>>
> >>
> >> So I drew 2 figures based on Table 14.2.
> >> No, I didn't actually drew them but wrote a rough program to generate .fig
> >> format files from the value changes of each CPU extracted from Table 14.2.
> >> I ignored the blank cells in the table just as in Figure 4.5.
> >> Appended is a tar ball of two files.
> >> out.fig is the overall diagram, and out-2.fig is a zoomed in view of
> >> the beginning part.
> >> I think they can provide a fairly interesting view of what's going on.
> >>
> >> Please give a look at them.
> > 
> > Not bad, actually!
> > 
> > The solid black areas need to be hatched or grey, otherwise it is a bit
> > hard on printers.  The colored areas look OK to me, though that does
> > not necessarily count for much.  ;-)
> 
> I'll see what I can.
> 
> > 
> > Would you like to send a patch replacing the table with these diagrams
> > and updating the text appropriately?
> 
> I'd love to!
> And may I remove the explanation of the "white cell situation" for now?
> Or do you want to keep those info in another set of diagrams which would
> depict the unresponsive periods in some way (translucent hatch or something)
> so that you could refer to them in a quick quiz you might come up with
> some day? 

I could add a quick quiz to the effect of "What about cache-miss latency?"

Let's start with the simple diagram and see how it looks.

							Thanx, Paul