On Jan 15, 2008, at 8:24 AM, Rainer Keller wrote:
- ompi_info shows whether this stuff is enabled
It shows the memchecker-valgrind mca.
Apart from showing the mca, no (so no separate line for
valgrind-kind-of-checking enabled).
If it should, we can do that of course... But I don't think it's
necessary.
Mmm -- good point. I forgot that this is a new framework. So, I
agree: if there's already a line in the ompi_info output about
memchecker support (through the listing of a component), then nothing
else is necessary.
- obvious user-level configure errors raise errors/abort configure
(E.g., --enable-memchecker is specified but --enable-debug is not),
or
make some obvious assumptions about "what the user meant" (e.g., if
--
enable-memchecker is specified by --enable-debug is not, then
automatically enable --enable-debug and output a message saying so).
Currently not done.
It is not really a requirement, though! (although it does not make
much sense
without).
I doubt that this has ever been mentioned before. It should be pretty
easy to do, though. It might be nice to spend the 15 minutes doing it
so that it doesn't get forgotten (says the guy who hasn't spent 15
minutes on it :-) ).
- I think we've said ad nauseam that there should be zero performance
penalty for when this stuff is not enabled, and I'm guessing that
this
is still true. :-)
100% ,-]
No code added in the default case.
- some kind of documentation should be written up about how to use
this stuff, perhaps in the FAQ (e.g., pairing it with a valgrind-
enabled libibverbs for max benefit, etc.).
Yep.
Will prepare a text, do You need it in HTML, or plain-text?
If you have the cycles, writing it up in the FAQ format would be
great. We use a mini-wiki format for common stuff in the FAQ.
I just added a wiki page about it:
https://svn.open-mpi.org/trac/ompi/wiki/OMPIFAQEntries
--
Jeff Squyres
Cisco Systems
