Re: Some questions

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

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