On Thu, 2009-05-28 at 05:57 -0600, Ralph Castain wrote:
> I agree with Terry here about being careful in pursuing this path.
> What I wouldn't want to have happen is to force anyone wanting to be
> notified of error events to have to also turn on peruse, which impacts
> the non-error code path.
Agreed, I missed that part!
Regards,
Nadia
>
> Again, I'm not entirely sure what you are trying to do here. As I
> understood the original RFC, it sounded like you wanted to track
> errors but only report them when they occurred a controlled number of
> times (as opposed to every time). I think this would better be done
> outside of peruse.
>
> If you are trying to track normal performance (e.g., trying to alert
> sys admins when networks aren't running as fast as they should), then
> that probably should be done inside of peruse. However, that
> definitely will impact the critical code path, so Terry's caution is
> definitely a concern.
>
>
> On Thu, May 28, 2009 at 12:55 AM, Nadia Derbey <nadia.der...@bull.net>
> wrote:
> On Wed, 2009-05-27 at 14:25 -0400, Jeff Squyres wrote:
> > Excellent points; Ralph and I chatted about this on the
> phone today --
> > we concur with George.
> >
> > Bull -- would peruse work for you? I think you mentioned
> before that
> > it didn't seem attractive to you.
>
>
> Well, it didn't because from what I understood, the MPI
> program need to
> be changed (register a callback routine for the event,
> activate the
> event, etc), and this is something we wanted to avoid.
>
> Now, if we are allowed to
> 1. define new "internal" PERUSE events,
> 2. internally set the associated callback routines
> why not using peruse? This combined with the orte notifier
> framework,
> could do the job I think.
>
> Regards,
> Nadia
>
>
> > I think George's point is that we
> > already have lots of hooks in place in the PML -- and
> they're called
> > peruse. So if we could use those hooks, then a) they're
> run-time
> > selectable already, and b) there's no additional cost in
> performance
> > critical/not-critical code paths (for the case where these
> stats are
> > not being collected) because PERUSE has been in the code
> base for a
> > long time.
> >
> > I think the idea is that your callbacks could be invoked by
> the peruse
> > hooks and then they can do whatever they want -- increment
> counters,
> > conditionally invoke the ORTE notifier system, etc.
> >
> >
> >
> > On May 27, 2009, at 11:34 AM, George Bosilca wrote:
> >
> > > What is a generic threshold? And what is a counter? We
> have a policy
> > > against such coding standards, and to be honest I would
> like to stick
> > > to it. The reason is that the PML is a very complex piece
> of code, and
> > > I would like to keep it as easy to understand as possible.
> If people
> > > start adding #if/#endif all over the code, we diverging
> from this
> > > goal.
> > >
> > > The only way to make this work is to call the notifier or
> some other
> > > framework in this "slow path" and let this other framework
> do it's own
> > > logic to determine what and when to print. Of course the
> cost of this
> > > is a function call plus an atomic operation (which is
> already not
> > > cheap). It's starting to get expensive, even for a "slow
> path", which
> > > in this particular context is just one insertion in an
> atomic FIFO.
> > >
> > > If instead of counting in number of times we try to send
> the fragment,
> > > and switch to a time base approach, this can be solved
> with the PERUSE
> > > calls. There is a callback when the request is created,
> and another
> > > callback when the first fragment is pushed successfully
> into the
> > > network. Computing the time between these two, allow a
> tool to figure
> > > out how much time the request was waiting in some internal
> queues, and
> > > therefore how much delay this added to the execution time.
> > >
> > > george.
> > >
> > > On May 27, 2009, at 06:59 , Ralph Castain wrote:
> > >
> > > > ORTE_NOTIFIER_VERBOSE(api, counter, threshold,...)
> > > >
> > > > #if WANT_NOTIFIER_VERBOSE
> > > > opal_atomic_increment(counter);
> > > > if (counter > threshold) {
> > > > orte_notifier.api(.....)
> > > > }
> > > > #endif
> > >
> > > _______________________________________________
> > > devel mailing list
> > > de...@open-mpi.org
> > > http://www.open-mpi.org/mailman/listinfo.cgi/devel
> > >
> >
> >
> --
>
> Nadia Derbey <nadia.der...@bull.net>
>
>
> _______________________________________________
> devel mailing list
> de...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/devel
>
>
> _______________________________________________
> devel mailing list
> de...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/devel
--
Nadia Derbey <nadia.der...@bull.net>
