Re: Some questions

[Akira Yokosawa <akiyks@gmail.com>]

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