There was a race condition in the eager get protocol where the RDMA complete message could be received before the local completion of the SMSG message that started the eager get protocol.
cmr:v1.7
This commit was SVN r27740.
- configure: fixed warnings from automake 1.12.x
Changes to VT:
- general:
- incremented version number to 5.14.2
- configure:
- fixed warnings from automake 1.12.x
- VT libs / MPI wrappers:
- do initialize VT and enter the dummy main function ("user") if MPI_Initialized is the very first event to be recorded (fixed assertion error)
- leave the dummy main function on the same thread where it is entered (fixes potential stack underflow)
This commit was SVN r27734.
* btl sendi(): if message can be send inline try to avoid signal
* signal is requested one per 64 or when
there are no send wqes
when message can not be send inline
any other btl method then sendi()
This commit was SVN r27724.
- configure: pass the MPI configure options (e.g. --with-mpi-lib, --with-mpi-inc-dir) to the OTF configure, even if MPI compiler wrappers were found
This commit was SVN r27710.
config/ directory. We split them apart a while ago in the hopes that
it would simplify things, but it didn't really (e.g., because there
were still some ompi/opal .m4 files in the top-level config/
directory, resulting in developer confusion where any given m4 macro
was defined).
So this commit consolidates them back into the top-level directory for
simplicity.
There's still (at least) two changes that would be nice to make:
1. Split any generated .m4 file (e.g., autogen-generated .m4 files)
into a separate directory somewhere so that a top-level -Iconfig/
will only get our explicitly defined macros, not the autogen stuff
(e.g., with libevent2019 needing to get the visibility macro, but
NOT all the autogen-generated inclusion of component configure.m4
files).
1. Change configure to be of the form:
{{{
# ...a small amount of preamble/setup...
OPAL_SETUP
m4_ifdef([project_orte], [ORTE_SETUP])
m4_ifdef([project_ompi], [OMPI_SETUP])
# ...a small amount of finishing stuff...
}}}
I doubt we'll ever get anything as clean as that, but that would be
the goal to shoot for.
This commit was SVN r27704.
- compiler wrappers: removed invocation of pdbcomment; it removes essential information from the PDB file for instrumenting functions
This commit was SVN r27687.
- otfprofile: fixed build error when using the IBM XL C++ compiler
Changes to VT:
- configure:
- use AC_CHECK_TYPES instead of AC_CHECK_DECLS to check for PAPI's long_long type
- use AC_C_INLINE to check whether C 'inline' is present
- VT libs:
- set CUPTI tracing as default, if CUDA runtime wrapper has not been built
- added a common interface for all NVIDIA CUPTI interfaces (events, activity, callbacks)
- added support for concurrent kernel tracing (since CUDA 5.0)
- removed almost unused VT_DEBUG env. variable - replaced calls to vt_debug_msg(DBG_LEVEL,...) by vt_cntl_msg (DBG_LEVEL+10,...)
- added some more ifdefs to new CUDA 5 features
- added several guards for internal malloc() and free() calls in CUDA related source files
- revised memory allocation tracing:
- intercept memory (de)alloaction functions by library wrapping (replaces deprecated hook technique from the GNU C library)
- added support for multi-threaded applications
- added wrapper functions for memalign, posix_memalign, and valloc
- revised exec,system,fork tracing
- retitled to "Child Process Execution Tracing"
- introduced env. variable VT_EXECTRACE (marked VT_LIBCTRACE as deprecated)
- added wrapper functions for execvpe, fexecve, waitid, wait3, and wait4
- changes default function group name for
- memory (de)allocation functions: "MEM" -> "LIBC-MALLOC"
- I/O functions: "I/O" -> "LIBC-I/O"
- child process execution: "LIBC" -> "LIBC-EXEC"
- plugin counter interface:
- added check for initialized vt_plugin_cntr_info.info
- vtdyn:
- added missing header includes for Dyninst 8
- vtrun:
- do not preload the Dyninst Runtime library; it is loaded by Dyninst itself
This commit was SVN r27679.
* Add some comments in the *-wrapper-data-txt.in files just so that
someone doesn't forget in the future why we link in what we do in
the MPI and ORTE wrapper compilers.
* Update ompi_wrapper_script.in to match the new behavior.
* Update orte_wrapper_script.in to support --openmpi:linkall (which
is a no-op in this case)
This commit was SVN r27672.
The following Trac tickets were found above:
Ticket 3422 --> https://svn.open-mpi.org/trac/ompi/ticket/3422
additional functionality. Rationale (refs trac:3422):
* Normal MPI applications only ever use the MPI API. Hence, -lmpi is
sufficient (they'll never directly call ORTE or OPAL
functions). This is arguably the most common case.
* That being said, we do have some test programs (e.g., those in
orte/test/mpi) that call MPI functions but also call ORTE/OPAL
functions. I've also written the occasional MPI test program that
calls opal_output, for example (there even might be a few tests in
the IBM test suite that directly call ORTE/OPAL functions).
* Even though this is not a common case, these applications should
also compile/link with mpicc.
* So we should add a --openmpi:linkall option that will also link
in whatever is necessary to call ORTE/OPAL functions
* Yes, we could hard-code "-lopen-rte -lopen-pal" in Makefiles, but
we do reserve the right to change those library names and/or add
others someday, so it's better to abstract out the names and let
the wrapper supply whatever is necessary.
* ORTE programs, however, are different. They almost always call OPAL
functions (e.g., if they want to send a message, they must use the
OPAL DSS). As such, it seems like the ORTE programs should always
link in OPAL.
Therefore:
* Add undocumented --openmpi:linkall flag to the wrapper compilers.
See the comment in opal_wrapper.c for an explanation of what it
does. This flag is only intended for Open MPI developers -- not
end users. That's why it's undocumented.
* Update orte/test/mpi/Makefile.am to add --openmpi:linkall
* Make ortecc/ortec++'s wrapper data text files always explicitly
link in libopen-pal
This commit was SVN r27670.
The following SVN revision numbers were found above:
r27668 --> open-mpi/ompi@cf845897aa
The following Trac tickets were found above:
Ticket 3422 --> https://svn.open-mpi.org/trac/ompi/ticket/3422
1. Restore libopen-pal.la, libopen-rte.la, and libmpi.la to be
separate entities (i.e., don't have libopen-rte.la include
libopen-pal.la, and don't have libmpi.la include libopen-pal.la).
Yay!
1. Consequently, make the wrapper compilers look for flags indicating
that the user wants to compile statically (currently: -static,
!--static, -Bstatic, and "-Wl," in front of all of those). If it
is, follow a 6-way matrix for determinining which libraries to
list on the underlying command line.
1. To support that, add the name of a token static and dynamic
library to look for in each of the wrapper compiler data files.
1. Fix a long-standing typo in the opalcc wrapper data file.
This commit was SVN r27662.
An upcoming BTL from Cisco used ofud as a starting point, and should
probably be used as a starting point for any future UD-based BTL.
And this OFUD BTL is obviously still in history if anyone ever wants
to resurrect it.
This commit was SVN r27655.
of modules, print a BTL_ERROR and exit(1) (previous behavior was to
segv). This at least explicitly tells the developer that their BTL
component is behaving badly.
This commit was SVN r27634.
- general:
- incremented version number to 1.12.2
- OTF library:
- implemented workaround for handling bogus zlib sync. points during reading
Changes to VT:
- general:
- incremented version number ot 5.14.1
- configure:
- to prevent conflicts with the libtool RPM, append "/vampirtrace" to ${datadir}, if it doesn't points to the default (=${datarootdir})
(Fixes trac:3382)
This commit was SVN r27630.
The following Trac tickets were found above:
Ticket 3382 --> https://svn.open-mpi.org/trac/ompi/ticket/3382
fbtl modules. This implmentation in alignment with all other collective modules tries to
keep all the file-ops as contiguous as possible.
This commit was SVN r27611.
Reasoning: The old behavior was a little confusing. mca_base_components_open does not open an output stream so it is a little unexpected that mca_base_components_close does. To add to this several frameworks (that don't use mca_base_components_close) failed to close their output in the framework close function and others closed their output a second time. This change is an improvement to the symantics of mca_base_components_open/close as they are now symetric in their functionality.
This commit was SVN r27570.
