Make sure that the wrapper selection is compiled out if not enabling FT. Before the
logic would skip over it since the conditional if statements would not be satisfied,
now there are no additional if statements when compiled out.
With this modification the selection logic looks nearly identical to pre-r14051
with the exception of the non-FT related improvements.
This commit was SVN r14491.
The following SVN revision numbers were found above:
r14051 --> open-mpi/ompi@dadca7da88
There is a binomial algorithm in the code (i.e., the HNP would send to a subset of the orteds, which then relay it on according to the typical log-2 algo), but that has a bug in it so the code won't let you select it even if you tried (and the mca param doesn't show, so you'd *really* have to try).
This also involved a slight change to the oob.xcast API, so propagated that as required.
Note: this has *only* been tested on rsh, SLURM, and Bproc environments (now that it has been transferred to the OMPI trunk, I'll need to re-test it [only done rsh so far]). It should work fine on any environment that uses the ORTE daemons - anywhere else, you are on your own... :-)
Also, correct a mistake where the orte_debug_flag was declared an int, but the mca param was set as a bool. Move the storage for that flag to the orte/runtime/params.c and orte/runtime/params.h files appropriately.
This commit was SVN r14475.
It's a bit longer, but much more clear in it's implementation I believe.
Fundamentally it is the same, but is much more solid in the implementation.
I created quite a few directed tests that this version of the implementation
now passes.
This commit was SVN r14457.
compiler suite. The rule is that ompi_info.h is supposed to be the
''first'' file included so that it can affect system header files if
necessary (and it is sometimes necessary, such as with the PGI
compiler suite).
If this breaks VC on Windows, we'll have to find another fix. More on
the mailing list...
This commit was SVN r14453.
The following SVN revision numbers were found above:
r14435 --> open-mpi/ompi@a20b43ace9
finally brings in functionality that is already on the 1.2 branch, and
was developed and tested in the v1.2ofed branch (and other places).
Short version of new features:
* Support for ibv_fork_init()
* Automatically fill in the openib BTL bandwidth value by
querying the HCA port
* Installdirs functionality
* Fixes to always use -I in the Fortran wrapper compilers (#924)
* Gleb's mpool updates
* Remove some kruft in btl/openib/configure.m4, therefore
fixing the harmless warnings noted in #665
* Bunches of updates to the Linux RPM spec file
I.e., effectively the same thing that r14411 brought to the v1.2
branch.
Also effectively brought in r14432 and r14433 (some fixes on top of
the original r14411 commit to v1.2). Still need to bring in the moral
equivalent of r14445 after this commit (fixes to installdirs).
This commit was SVN r14449.
The following SVN revision numbers were found above:
r14411 --> open-mpi/ompi@83b31314ae
r14432 --> open-mpi/ompi@a48f160595
r14433 --> open-mpi/ompi@68f346d2bc
r14445 --> open-mpi/ompi@13d366b827
- Move the PML Modex stuff out of the BML -- Abstraction violation.
- Also fix the location of the add_procs with respect to the stage gates.
This commit was SVN r14422.
to move it into the unexpected queue. Instead pack the data in
only one buffer. Now the code look more optimized and clear, but
I have a doubt about who's using this functionality. I think that
all BTLs always return only one memory segment attached to the
matching fragment (i.e. there is no unexpected iov type receive).
This commit was SVN r14416.
function to make it more scalable. The memory fragmentation is still high, but
at least in most of the cases (where all ressources are correctly released
before the cleanup) the code is now highly efficient. Before the code execute
in (N * (N-1))!, which take a while when the number of allocated ressources
increase (which is the case when a lot of unexpected messages are created).
The fix consist of checking if all items are freed and if it's the case
then do not recreate the free items list (as we know that everything will
be released). If this condition is not true, we fall back on the
original execution path (which is still sub-sub-sub ... optimal).
This commit was SVN r14406.
same "restrict" check as the top-level OMPI configure.ac script so
that it will guarantee to always get the same result. Therefore, the
#define for restrict will always have the same value in both
opal_config.h and romioconf.h, and we get 7 less warnings (6 in the IO
ROMIO component, 1 in ROMIO itself) when compiling with icc on Linux
(because PAC_C_RESTRICT and AC_C_RESTRICT would get different values
for the "restrict" #define in this case).
This commit was SVN r14387.
Fix for memory corruption in the restarted process stack. This stemed from
the brute force method we were previously using. This commit fixes this by
using a lighter weight solution focused in the r2 BML instead of above the PML.
This is a more efficient and flexible solution, and it solves the original
problem.
In the process I pulled out the ft_event function in the tcp BTL and r2 BML
into a set of *_ft.[c|h] files just to keep any updates to these code paths
as isolated as possible to make merging easier on everyone.
This commit was SVN r14371.
The following SVN revision numbers were found above:
r2 --> open-mpi/ompi@58fdc18855
The following Trac tickets were found above:
Ticket 977 --> https://svn.open-mpi.org/trac/ompi/ticket/977
Per discussions with Brian and Ralph, make a slight correction in
where components are installed. Use $pkglibdir, not $libdir/openmpi,
so that when compiled in the orte trunk, components are installed to
the right directory (because the component search patch is checking
$pkglibdir).
This commit was SVN r14345.
The following SVN revisions from the original message are invalid or
inconsistent and therefore were not cross-referenced:
r14289
the real interest is for small to middle size unexpected messages. The unexpected messages are copied
by the PML in it's own unexpected buffers. Therefore, there is no reason to make a first copy in the
TCP BTL. The BTL can handle to the PML it's own buffer, and can be sure that once the callback
completed it can reuse the buffer, no matter what happened with the fragment.
This commit was SVN r14320.
time difference...
1) The PML makes an assumption on local/remote completion semantics of the BTL
which Self BTL does not obey, nor should it, so we fix the PML
2) The Get protocol must handle the case when sender and reciever do not agree
on wheter the data is contiguous
This commit was SVN r14313.
Sorry for configure changes during the day; I totally forgot about
that. :-(
This commit was SVN r14288.
The following SVN revision numbers were found above:
r14286 --> open-mpi/ompi@0083eba18e
The top-level OMPI configure script already checks for "restrict" and
will issue a #define for it. PAC_C_RESTRICT would also check for
restrict, but sometimes come up with a different answer than the
top-level OMPI configure script, thereby resulting in conflicting
#define's for "restrict" (e.g., icc 9.0/9.1 on linux x86-64).
So it's easiest just to remove this test from ROMIO's configure.in
script.
This commit was SVN r14286.
Remove a redundant statement in the r2 BML.
This commit was SVN r14228.
The following SVN revision numbers were found above:
r2 --> open-mpi/ompi@58fdc18855
- Remove an old comment from crcp_base_fns.c
- Let ob1 have its very own ft_event function (which I'll fill in shortly)
- Make sure ob1 finalizes the bsend stuff so we don't leave a bunch of memory sitting around
- PML base - destruct the array upon finalize. Shrink the include search so it stops after finding a match
This commit was SVN r14222.
creating ompi_mpi_comm_null, since the destructor of ompi_mpi_comm_null will
decrease the reference counter of ompi_mpi_group_null twice according to the
last fix of Mohamad.
Added also a lengthy comment in ompi_comm_finalize about why we do
not decrease the reference counters for ompi_mpi_comm_null,
ompi_mpi_group_null etc. for the parent
communicator, although we do increase it in ompi_comm_init
This commit was SVN r14210.
when the size of the data is zero. Now they are not updated, which leave
us with the correct memory layout in all situations (so far). Update all
the comments to reflect exactly the supported behavior of the DDT engine.
This commit was SVN r14202.
