[mpiwg-tools] reset a stopped pvar

[Junchao Zhang]

Also, for a stopped pvar, after reset and before restarting, what does a
pvar_read return?
Returning zero sounds good for counters? What about watermarks? Old value,
garbage value or MPI_T_ERROR_XXX? I would choose ERROR.
The side-effect is that it makes resetting pvars not beautiful.

--Junchao Zhang


On Thu, Sep 19, 2013 at 12:32 AM, Martin Schulz <schulzm at llnl.gov> wrote:

> Hmm, that is a good catch. I agree with Kathryn's interpretation - in
> particular the use case she is laying out. If one does:
>
> Reset
> Start
> Stop
>
> You want the watermark from that interval, i.e., the starting value as of
> the start call should be the right thing. This is something we definitely
> should clarify.
>
> Thanks,
>
> Martin
>
>
>
> On Sep 18, 2013, at 8:33 PM, Kathryn Mohror <kathryn at llnl.gov>
>  wrote:
>
> Hi Junchao,
>
>   What is the right behavior when resetting a stopped pvar? The standard
> says setting to its starting value.
>   For counters, timers etc, setting them to zero sounds reasonable.
>   But for a watermark, setting it to "the current utilization level" looks
> weird. It implies that a value caught during the stopped period can affect
> its future value when the pvar is re-started.
>   Probably, we should reset a stopped watermark to a state as if it has
> never been started.
>   Any comments?  Thanks
>
>
> Hmm. It makes sense to me, but I'll let others chime in if they disagree.
> I think that the moment you start the watermark variable, you want to know
> what the "mark" is, so it would be the value of current utilization. So
> even if a higher (or lower) value is caught during the stopped period
> (which it shouldn't be, because variables aren't supposed to be updated
> when stopped), it will be set to the current utilization value when
> started. I interpret this as being able to measure the watermark during
> different epochs of the program execution. Every time you start the
> variable, it's a fresh epoch and you want to know what the watermark was
> during that epoch.
>
> However, I can see how this isn't clear as it could be -- I'll try to see
> what we can do to clarify it in the text.
>
> Thanks again for taking the time to give us this feedback.
>
> Kathryn
>
>
> --Junchao Zhang
>  _______________________________________________
> mpiwg-tools mailing list
> mpiwg-tools at lists.mpi-forum.org
> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools
>
>
> ______________________________________________________________
> Kathryn Mohror, kathryn at llnl.gov, http://people.llnl.gov/mohror1
> CASC @ Lawrence Livermore National Laboratory, Livermore, CA, USA
>
>
>
>
> _______________________________________________
> mpiwg-tools mailing list
> mpiwg-tools at lists.mpi-forum.org
> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools
>
>
> ________________________________________________________________________
> Martin Schulz, schulzm at llnl.gov, http://people.llnl.gov/schulzm
> CASC @ Lawrence Livermore National Laboratory, Livermore, USA
>
>
> _______________________________________________
> mpiwg-tools mailing list
> mpiwg-tools at lists.mpi-forum.org
> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mpi-forum.org/pipermail/mpiwg-tools/attachments/20130919/1bcb9140/attachment-0001.html>