Re: Some questions

["Paul E. McKenney" <paulmck@linux.vnet.ibm.com>]

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