(1) As pointed out by Torsten after Jeff comment that there are 15 collectives yesterday.. nope.. I have 16 but
miss counted them in my ifdefs (I had two #11s). Replaces with enum...
(2) Added a readonly MCA param for how many backend algorithms are available per collective (used by benchmarker/STS)
This allowed me to remove the tuned query internal functions and replace them with ompi_coll_tuned_forced_max_algorithms[COLL].
(3) I was reading the user forced MCA params for the collectives on each comm create (module init) but I then put the
values into a global set of variables (like ompi_coll_tuned_reduce_forced_algorithm).
To fix this and make the code neater:
(a) The component looks up the MCA param indices on Open if dynamic_rules is set via the
ompi_coll_tuned_COLLECTIVE_intra_check_forced_init () call.
(b) Got rid of the ompi_coll_ompi_coll_tuned_COLLECTIVE_forced_algorithm/segmentsize/etc globals with a struct that
is now cached on the module data hung off the communicator. i.e. done right.
(c) On module init if dynamic rules enabled we call a general getvalues routine (in coll_tuned_forced.c) to get the
CURRENT values using the MCA param indices and then put them on the modules data segment.
A shorter version of getvalues exists for barrier which only needs the algorithm choice
This commit was SVN r9663.
- Some initial work on prepare_src
- Move some fragment initialization around
- Fix a union casting issue on picky compilers, identified by Don Kerr
- Other small cleanups/bugfixes
This commit was SVN r9662.
- include stdlib.h for tests that call exit(), as AC no longer
prototypes exit in 2.60
- Fix a compile issue in our cross-compiling test for C/C++
alignment checks, matching what AC did for 2.60.
This commit was SVN r9634.
- My original patch stands: MPI_FINALIZE directly invokes the
attribute callbacks on MPI_COMM_SELF
- We added some user-level checks to ensure that they don't call
MPI_FINALIZE twice (this isn't really required, but it will prevent
whacky segv's -- they'll at least get a nice error message)
- Removed the attribute callbacks on MPI_COMM_SELF from
ompi_mpi_comm_finalize (i.e., we just moved them from
ompi_mpi_comm_finalize to ompi_mpi_finalize -- we just moved this
process up earlier in the MPI_FINALIZE sequence of events)
- Because there were so many conversations about this, here's the
rationale:
- MPI-2:4.8 says that we have to MPI_COMM_FREE MPI_COMM_SELF so that
the attribute callbacks are invoked.
- After considerable discussion, we came to the conclusion that
FREE'ing COMM_SELF is not the issue -- calling the callbacks is
the issue.
- So it is sufficent for MPI_FINALIZE to directly invoke these
attribute callbacks
- The attribute callbacks are *not* invoked on other communicators
because said communicators are not MPI_COMM_FREE'ed
This commit was SVN r9628.
Copy the Doxyfile to orte so people can generate just that documentation. Adjust the properties on that directory so it ignores the resulting doxygen output tree.
This should go over to the release branch(es)
This commit was SVN r9625.
The free lst using atomic operations. I didn't want to completely
change the behavior, so we still use a mutex for the extreme cases (like
no more available items and we cannot allocate more). I test it for a
while on non multi-threading environment, but not enough on a multi-threaded
build.
This commit was SVN r9623.
svn merge -r 9453:9609 https://svn.open-mpi.org/svn/ompi/tmp/f90-stuff .
Several improvements over the current F90 MPI bindings:
- The capability to make 4 sizes of the F90 bindings:
- trivial: only the F90-specific MPI functions (sizeof and a few
others)
- small: (this is the default) all MPI functions that do not take
choice buffers
- medium: small + all MPI functions that take one choice buffer
(e.g., MPI_SEND)
- large: all MPI functions, but those that take 2 choice buffers
(e.g., MPI_GATHER) only allow both buffers to be of the same type
- Remove all non-standard MPI types (LOGICAL*x, CHARACTER*x)
- Remove use of selected_*_kind() and only use MPI-defined types
(INTEGER*x, etc.)
- Decrease complexity of the F90 configure and build system
This commit was SVN r9610.
we send our local addr_t OOB. Remote side then matches endpoints and calls
dat_ep_connect(). Everything should be the same as before from here, except
that client/server roles are reversed.
- Properly set our buffer size when posting receives. When the frag used to
transfer address information is recycled by the free list, the wrong buffer
size was being used, which caused buffer overflow errors.
- Finally put the uDAPL error handling stuff in the mpool component.
- Remove a few more OPAL_OUTPUTs.
This commit was SVN r9569.
functions return an invalid fortran handle (-1) if an invalid C handle
is passed in.
Just so it's logged somewhere -- it looks like commit 2 of 2 as noted
in the r9560 commit message (ok, 3 of 3 if you're really counting),
where we have to edit the C interface functions to check for NULL, is
going to be far easier than I thought -- many (but not all) of the C
interface functions already check for NULL MPI handles (either
directly or through helper functions).
Woo hoo for foresight...
This commit was SVN r9561.
The following SVN revision numbers were found above:
r9560 --> open-mpi/ompi@e00c6053dc
handling of invalid Fortran handles. Per MPI-2:4.12.4, if we get an
invalid Fortran handle, we should return an invalid C handle. Before
this commit, we checked if the fortran handle index was out of range
(i.e., <0 or >sizeof(array)). If so, we used to return MPI_*_NULL
(i.e., a valid C handle). But to be faithful to MPI-2:4.12.4, we
now return NULL (an invalid C handle).
If the fortran index is in bounds but is an index for an MPI object
that has already been freed, the code already returns NULL because the
entry in the array will be NULL (i.e., we already did what
MPI-2:4.12.4 said for this case).
Hence, this commit makes the handling of invalid fortran handles in
the MPI_*_F2C functions be uniform: we always return NULL.
Commit 2 of this will be to edit just about every C interface function
(!) to ensure that MPI handles are not NULL. Otherwise, if the user
calls a fortran interface function with an invalid handle, the fortran
interface function will call MPI_*_F2C and blindly pass the result to
the back-end C function. The C function will eventually end up trying
to dereference it -- segv. Having a run-time check for NULL and
invoking an MPI exception is far more social (e.g., the user can get a
stack trace out of MPI_ABORT) and consistent (i.e., we're already
checking for MPI_*_NULL in the C interface functions).
Since all the C interface functions have all the machinery for
run-time parameter checking, and they all already check for
MPI_*_NULL, it's easy enough to add another check for NULL.
This commit was SVN r9560.
thread, which will do progress independently of MPI. So in this case we
have to call opal_event_loop instead of opal_progress.
This commit was SVN r9551.
event library (since the event library has its own thread). So when
we are using progress threads, we really want to call opal_event_loop()
and not opal_progres().
This commit was SVN r9549.
as I understand how that one works and don't really understand what
was in the amd64 code (which was copied from before I started working
on the inline assembly). This fixes the race condition we were
seeing on PGI causing test failures
* sync non-inline assembly with inline assembly version
This needs to go to the v1.0 branch
This commit was SVN r9539.
to use the appropriate macro for all the Fortran .TRUE. handling, or
things get misinterpeted and, with some compilers, it will look like
the attribute wasn't copied properly.
This commit was SVN r9536.
implementations. I dont want to overload the memcpy functions,
therefore people interested in using the high performance memcpy
should use directly opal_memcpy instead. Notice, that there are 2
other versions of memcpy available, which use a destination or a source
described as iovecs.
This commit was SVN r9532.
