lower the default priority to 0 so that it's not active unless you
specifically ask for it (this component needs more testing by people
other than me before we unleash it on the public).
This commit was SVN r7545.
- finally added "in use" flags -- one flag protects a set of segments
- these flags now used in bcast to protect (for example) when a
message is so long that the root loops around the segments and has
to re-use old segments -- now it knows that it has to wait until the
non-root processes have finished with that set of segments before it
can start using them
- implement allreduce as a reduce followed by a bcast (per discussion
with rich)
- removed some redundant data on various data structures
- implemented query MCA param ("coll_sm_shared_mem_used_data") that
tells you how much shared memory will be used for a given set of MCA
params (e.g., number of segments, etc.). For example:
ompi_info --mca coll_sm_info_num_procs 4 --param coll sm | \
grep shared_mem_used_data
tells you that for the default MCA param values (as of r7172), for 4
processes, sm will use 548864 bytes of shared memory for its data
transfer section
- remove a bunch of .c files from the Makefile.am that aren't
implemented yet (i.e., all they do is return ERR_NOT_IMPLEMENTED)
Now on to the big Altix to test that this stuff really works...
This commit was SVN r7205.
The following SVN revision numbers were found above:
r7172 --> open-mpi/ompi@bc72a7722b
- bcast now works properly for root!=0 and multi-fragment messages
- destroy mpool when communicator is destroyed
Still need to implement:
- "in use" flags for groups of fragments so that "wrapping around" in
the data segment doesn't overwrite not-yet-read data
- ensure that shared memory isn't removed before all processes have
finished with it (e.g., during COMM_FREE)
This commit was SVN r7172.
much time) and somewhat-lame implementation of barrier (need to
precompute some more stuff rather than calculate it every time).
Checkpointing so I can try this on another machine...
This commit was SVN r6985.
multiple components to share a single mpool module (e.g., the
ptl/btl and coll sm components).
- Re-tool the ptl, btl, and coll sm components to first look for the
target mpool module, and if they don't find it, to create it.
- coll sm component now correctly identifies when it is supposed to
run or not (i.e., if all the processes in the communicator are on
the same host). Now we just need to fill in some algorithms. :-)
This commit was SVN r6530.
- After long discussions and ruminations on how we run components in
LAM/MPI, made the decision that, by default, all components included
in Open MPI will use the version number of their parent project
(i.e., OMPI or ORTE). They are certaint free to use a different
number, but this simplification makes the common cases easy:
- components are only released when the parent project is released
- it is easy (trivial?) to distinguish which version component goes
with with version of the parent project
- removed all autogen/configure code for templating the version .h
file in components
- made all ORTE components use ORTE_*_VERSION for version numbers
- made all OMPI components use OMPI_*_VERSION for version numbers
- removed all VERSION files from components
- configure now displays OPAL, ORTE, and OMPI version numbers
- ditto for ompi_info
- right now, faking it -- OPAL and ORTE and OMPI will always have the
same version number (i.e., they all come from the same top-level
VERSION file). But this paves the way for the Great Configure
Reorganization, where, among other things, each project will have
its own version number.
So all in all, we went from a boatload of version numbers to
[effectively] three. That's pretty good. :-)
This commit was SVN r6344.
