Re: Some questions

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

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