for dynamic selection of cpc methods based on what is available. It
also allows for inclusion/exclusions of methods. It even futher allows
for modifying the priorities of certain cpc methods to better determine
the optimal cpc method.
This patch also contains XRC compile time disablement (per Jeff's
patch).
At a high level, the cpc selections works by walking through each cpc
and allowing it to test to see if it is permissable to run on this
mpirun. It returns a priority if it is permissable or a -1 if not. All
of the cpc names and priorities are rolled into a string. This string
is then encapsulated in a message and passed around all the ompi
processes. Once received and unpacked, the list received is compared
to a local copy of the list. The connection method is chosen by
comparing the lists passed around to all nodes via modex with the list
generated locally. Any non-negative number is a potentially valid
connection method. The method below of determining the optimal
connection method is to take the cross-section of the two lists. The
highest single value (and the other side being non-negative) is selected
as the cpc method.
svn merge -r 16948:17128 https://svn.open-mpi.org/svn/ompi/tmp-public/openib-cpc/ .
This commit was SVN r17138.
<prog>`}}} in `configure`. It is preferable to simply using {{{`which
<prog>`}}} because backticks (`) (aka backquotes) invoke a sub-shell
which may source a "noisy" `~/.whatever` file, and we do not want the
error messages to be part of the assignment in {{{foo=`which
<prog>`}}}.
This commit was SVN r16955.
cover the case where a subdirectory is also built that needs to be
removed.
Note that there are other macros that we don't control (AC, AM, and/or
LT) that also exhibit this problem that we cannot fix. :-\
Fixes trac:1180.
This commit was SVN r16669.
The following Trac tickets were found above:
Ticket 1180 --> https://svn.open-mpi.org/trac/ompi/ticket/1180
methods (in order of precedence):
1. #pragma ident <ident string> (e.g., Intel and Sun)
1. #ident <ident string> (e.g., GCC)
1. static const char ident[] = <ident string> (all others)
By default, the ident string used is the standard Open MPI version string. Only
the following libraries will get the embedded version strings (e.g., DSOs will
not):
* libmpi.so
* libmpi_cxx.so
* libmpi_f77.so
* libopen-pal.so
* libopen-rte.so
* Added two new configure options:
* `--with-package-name="STRING"` (defaults to "Open MPI username@hostname
Distribution"). `STRING` is displayed by `ompi_info` next to the "Package"
heading.
* `--with-ident-string="STRING"` (defaults to the standard Open MPI version
string - e.g., X.Y.Zr######). `%VERSION%` will expand to the Open MPI
version string if it is supplied to this configure option.
This commit was SVN r16644.
{{{
OMPI_VAR_SCOPE_PUSH([var1 var2 var3])
...use $var1 $var1 and $var3
OMPI_VAR_SCOPE_PUSH([var4 var5 var6])
...use $var1 $var1 and $var3
...use $var4 $var5 and $var6
OMPI_VAR_SCOPE_POP
...use $var1 $var1 and $var3
OMPI_VAR_SCOPE_POP
}}}
The PUSH macro does a simple sanity check to ensure that the variables
listed are not already set with other values. If they are set, it
will abort configure, assuming that this is a programming error. If
none of the names are set as environment variables containing values,
the names are saved for later POP'ing. The POP will unset all the
variables from a corresponding PUSH.
As the names imply, these macros effect a stack-like behavior. So a
POP must correspond to a PUSH, etc.
These macros are intended to be simple sanity checks for OMPI
configure programmers, and also help keep the environment clean by
unsetting variables when they are no longer used.
This commit was SVN r16592.
config/ompi_check_visibility.m4 (OMPI_CHECK_VISIBILITY):
Rename ompi_vc_cc_fvisibility to ompi_cv_cc_fvisibility, so
that it will be cached.
This commit was SVN r16435.
1. --with-sge, always builds
2. --without-sge, never builds
3. if neither is specified, build if and only if either SGE_ROOT is set or "qrsh" is found in the path
This commit was SVN r16422.
The commit has been tested for C/R and Cray operations, and on Odin (SLURM, rsh) and RoadRunner (TM). I tried to update all environments, but obviously could not test them. I know that Windows needs some work, and have highlighted what is know to be needed in the odls process component.
This represents a lot of work by Brian, Tim P, Josh, and myself, with much advice from Jeff and others. For posterity, I have appended a copy of the email describing the work that was done:
As we have repeatedly noted, the modex operation in MPI_Init is the single greatest consumer of time during startup. To-date, we have executed that operation as an ORTE stage gate that held the process until a startup message containing all required modex (and OOB contact info - see #3 below) info could be sent to it. Each process would send its data to the HNP's registry, which assembled and sent the message when all processes had reported in.
In addition, ORTE had taken responsibility for monitoring process status as it progressed through a series of "stage gates". The process reported its status at each gate, and ORTE would then send a "release" message once all procs had reported in.
The incoming changes revamp these procedures in three ways:
1. eliminating the ORTE stage gate system and cleanly delineating responsibility between the OMPI and ORTE layers for MPI init/finalize. The modex stage gate (STG1) has been replaced by a collective operation in the modex itself that performs an allgather on the required modex info. The allgather is implemented using the orte_grpcomm framework since the BTL's are not active at that point. At the moment, the grpcomm framework only has a "basic" component analogous to OMPI's "basic" coll framework - I would recommend that the MPI team create additional, more advanced components to improve performance of this step.
The other stage gates have been replaced by orte_grpcomm barrier functions. We tried to use MPI barriers instead (since the BTL's are active at that point), but - as we discussed on the telecon - these are not currently true barriers so the job would hang when we fell through while messages were still in process. Note that the grpcomm barrier doesn't actually resolve that problem, but Brian has pointed out that we are unlikely to ever see it violated. Again, you might want to spend a little time on an advanced barrier algorithm as the one in "basic" is very simplistic.
Summarizing this change: ORTE no longer tracks process state nor has direct responsibility for synchronizing jobs. This is now done via collective operations within the MPI layer, albeit using ORTE collective communication services. I -strongly- urge the MPI team to implement advanced collective algorithms to improve the performance of this critical procedure.
2. reducing the volume of data exchanged during modex. Data in the modex consisted of the process name, the name of the node where that process is located (expressed as a string), plus a string representation of all contact info. The nodename was required in order for the modex to determine if the process was local or not - in addition, some people like to have it to print pretty error messages when a connection failed.
The size of this data has been reduced in three ways:
(a) reducing the size of the process name itself. The process name consisted of two 32-bit fields for the jobid and vpid. This is far larger than any current system, or system likely to exist in the near future, can support. Accordingly, the default size of these fields has been reduced to 16-bits, which means you can have 32k procs in each of 32k jobs. Since the daemons must have a vpid, and we require one daemon/node, this also restricts the default configuration to 32k nodes.
To support any future "mega-clusters", a configuration option --enable-jumbo-apps has been added. This option increases the jobid and vpid field sizes to 32-bits. Someday, if necessary, someone can add yet another option to increase them to 64-bits, I suppose.
(b) replacing the string nodename with an integer nodeid. Since we have one daemon/node, the nodeid corresponds to the local daemon's vpid. This replaces an often lengthy string with only 2 (or at most 4) bytes, a substantial reduction.
(c) when the mca param requesting that nodenames be sent to support pretty error messages, a second mca param is now used to request FQDN - otherwise, the domain name is stripped (by default) from the message to save space. If someone wants to combine those into a single param somehow (perhaps with an argument?), they are welcome to do so - I didn't want to alter what people are already using.
While these may seem like small savings, they actually amount to a significant impact when aggregated across the entire modex operation. Since every proc must receive the modex data regardless of the collective used to send it, just reducing the size of the process name removes nearly 400MBytes of communication from a 32k proc job (admittedly, much of this comm may occur in parallel). So it does add up pretty quickly.
3. routing RML messages to reduce connections. The default messaging system remains point-to-point - i.e., each proc opens a socket to every proc it communicates with and sends its messages directly. A new option uses the orteds as routers - i.e., each proc only opens a single socket to its local orted. All messages are sent from the proc to the orted, which forwards the message to the orted on the node where the intended recipient proc is located - that orted then forwards the message to its local proc (the recipient). This greatly reduces the connection storm we have encountered during startup.
It also has the benefit of removing the sharing of every proc's OOB contact with every other proc. The orted routing tables are populated during launch since every orted gets a map of where every proc is being placed. Each proc, therefore, only needs to know the contact info for its local daemon, which is passed in via the environment when the proc is fork/exec'd by the daemon. This alone removes ~50 bytes/process of communication that was in the current STG1 startup message - so for our 32k proc job, this saves us roughly 32k*50 = 1.6MBytes sent to 32k procs = 51GBytes of messaging.
Note that you can use the new routing method by specifying -mca routed tree - if you so desire. This mode will become the default at some point in the future.
There are a few minor additional changes in the commit that I'll just note in passing:
* propagation of command line mca params to the orteds - fixes ticket #1073. See note there for details.
* requiring of "finalize" prior to "exit" for MPI procs - fixes ticket #1144. See note there for details.
* cleanup of some stale header files
This commit was SVN r16364.
static builds for OMPI components that required extra LIBS or LDFLAGS
(e.g., the openib BTL).
Fixes trac:1155.
This commit was SVN r16314.
The following SVN revision numbers were found above:
r15900 --> open-mpi/ompi@50941ec389
The following Trac tickets were found above:
Ticket 1155 --> https://svn.open-mpi.org/trac/ompi/ticket/1155
Minor change to ompi_mca.m4 to move AC_CONFIG_FILES(framework/makefile) in autogen process (instead of configure process), where we still now the actual framework path (instead of guessing using $project/mca/$framework).
This have shown no side effects in our testing. Let us know if this breaks one of your components in some exotic context.
This commit was SVN r16146.
used at nce (up to one unique collective module per collective function).
Matches r15795:15921 of the tmp/bwb-coll-select branch
This commit was SVN r15924.
The following SVN revisions from the original message are invalid or
inconsistent and therefore were not cross-referenced:
r15795
r15921
only static libraries. Previously, we were linking the libraries into
directly into the common, btl, and mtl code. This seemed to work fine
for me on my Opteron Fedora box, but caused Lisa some issues (PtlNIInit
would succeed, but the network handle would fail when used with
PtlEQAlloc).
Instead, link the portals libraries directly into libmpi and not at
all into the common, btl, or mtl components. THen use some linker
tricks to force the linker to bring in the public interface for the
reference implementation (which thankfully is pretty small).
This commit was SVN r15902.
disable the building of the udapl BTL on Linux by default. On every
other OS, the udapl configury will attempt to find udapl's
header/library files, etc. by default.
You can specify --with-udapl on the configure command line (on any OS)
to force OMPI to try to configure/build udapl (i.e., look for udapl's
header/library files, etc.).
This commit was SVN r15894.
1. Galen's fine-grain control of queue pair resources in the openib
BTL.
1. Pasha's new implementation of asychronous HCA event handling.
Pasha's new implementation doesn't take much explanation, but the new
"multifrag" stuff does.
Note that "svn merge" was not used to bring this new code from the
/tmp/ib_multifrag branch -- something Bad happened in the periodic
trunk pulls on that branch making an actual merge back to the trunk
effectively impossible (i.e., lots and lots of arbitrary conflicts and
artifical changes). :-(
== Fine-grain control of queue pair resources ==
Galen's fine-grain control of queue pair resources to the OpenIB BTL
(thanks to Gleb for fixing broken code and providing additional
functionality, Pasha for finding broken code, and Jeff for doing all
the svn work and regression testing).
Prior to this commit, the OpenIB BTL created two queue pairs: one for
eager size fragments and one for max send size fragments. When the
use of the shared receive queue (SRQ) was specified (via "-mca
btl_openib_use_srq 1"), these QPs would use a shared receive queue for
receive buffers instead of the default per-peer (PP) receive queues
and buffers. One consequence of this design is that receive buffer
utilization (the size of the data received as a percentage of the
receive buffer used for the data) was quite poor for a number of
applications.
The new design allows multiple QPs to be specified at runtime. Each
QP can be setup to use PP or SRQ receive buffers as well as giving
fine-grained control over receive buffer size, number of receive
buffers to post, when to replenish the receive queue (low water mark)
and for SRQ QPs, the number of outstanding sends can also be
specified. The following is an example of the syntax to describe QPs
to the OpenIB BTL using the new MCA parameter btl_openib_receive_queues:
{{{
-mca btl_openib_receive_queues \
"P,128,16,4;S,1024,256,128,32;S,4096,256,128,32;S,65536,256,128,32"
}}}
Each QP description is delimited by ";" (semicolon) with individual
fields of the QP description delimited by "," (comma). The above
example therefore describes 4 QPs.
The first QP is:
P,128,16,4
Meaning: per-peer receive buffer QPs are indicated by a starting field
of "P"; the first QP (shown above) is therefore a per-peer based QP.
The second field indicates the size of the receive buffer in bytes
(128 bytes). The third field indicates the number of receive buffers
to allocate to the QP (16). The fourth field indicates the low
watermark for receive buffers at which time the BTL will repost
receive buffers to the QP (4).
The second QP is:
S,1024,256,128,32
Shared receive queue based QPs are indicated by a starting field of
"S"; the second QP (shown above) is therefore a shared receive queue
based QP. The second, third and fourth fields are the same as in the
per-peer based QP. The fifth field is the number of outstanding sends
that are allowed at a given time on the QP (32). This provides a
"good enough" mechanism of flow control for some regular communication
patterns.
QPs MUST be specified in ascending receive buffer size order. This
requirement may be removed prior to 1.3 release.
This commit was SVN r15474.
VxWorks. Still some issues remaining, I'm sure.
Refs trac:1010
This commit was SVN r15320.
The following Trac tickets were found above:
Ticket 1010 --> https://svn.open-mpi.org/trac/ompi/ticket/1010
types and add STOP_AT_FIRST_PRIORITY type for framework configuration,
which allows all components at the highest priority that succeeds to
succeed
* Use STOP_AT_FIRST_PRIORITY type for gpr framework, so that the null
component isn't built when the replica and proxy components are
available.
This commit was SVN r15286.
libsysfs headers are required for libibverbs v1.0 (i.e., OFED 1.0 and
OFED 1.1), meaning that <infiniband/verbs.h> would #include
<sysfs/libsysfs.h>. Hence, if the libsysfs headers did not exist on a
system, including <verbs.h> would fail.
With older versions of Autoconf, we would simply test for the
''presence'' of the <infinband/verbs.h> and not actually try to
''use'' it. This could leave OMPI in a weird situation on systems
that did not have the sysfs headers installed: configure would
complete successfully, but the build of the openib btl would fail.
Some users complained, thinking that there was a real compile error in
the OMPI code base.
Hence, we decided that it would be better to AC_CHECK_HEADER for the
sysfs header files in configure. If the sysfs header files were not
found, configure would abort. Users generally understand when
configure aborts, and know how to read the output and fix the
underlying problem; it was ''much'' more obvious than having the OMPI
build fail for nebulous reasons much later.
Note that we also checked for / added -lsysfs, but that wasn't
necessary because libibverbs already run-time linked to it (i.e.,
libibverbs couldn't have been installed if the sysfs libraries weren't
installed).
However, there are now two reasons why the check for sysfs's header
files is no longer necessary:
* Newer versions of Autoconf are now used for OMPI tarballs that
check for both the presence '''and''' usability of header files.
Hence, AC_CHECK_HEADER for <infiniband/verbs.h> will actually try
to ''use'' it, so if the sysfs header files are not installed,
AC_CHECK_HEADER will (rightfully) fail.
* libibverbs v1.1 (i.e., OFED 1.2 and beyond) does not require
libsysfs at all (headers or libraries).
When checking for the sysfs header files, OMPI's configure ''forces''
you to have sysfs installed, even though it may not be needed (e.g.,
libibverbs v1.1 and beyond). Clearly, this is not good (especially
since the sysfs software package is now deprecated, and some Linux
distros no longer install it by default).
So this commit simply removes the check for the sysfs header files and
libraries, allowing OMPI to be build on systems with libibverbs >=1.1 that
do not have sysfs installed.
For systems with libibverbs 1.0, if they do not have the sysfs headers
installed, we'll still fail AC_CHECK_HEADER and therefore still fail
configure properly. I expanded the warning message to say that if
libibverbs 1.0 is being used, check to ensure that sysfs is installed,
yadda yadda yadda.
This commit was SVN r14971.
The following Trac tickets were found above:
Ticket 1045 --> https://svn.open-mpi.org/trac/ompi/ticket/1045
have the SRQ interface.
* Instead of setting AC_DEFINEs per MCA component, set per test. THe
answers can never be difference, and this will speed sed just a teeny
bit
This commit was SVN r14856.
-I for ${includedir}/openmpi. Solves many problems, and with just a tad
bit of hackery. Don't know why I didn't just do this earlier.
Refs trac:542
This commit was SVN r14853.
The following Trac tickets were found above:
Ticket 542 --> https://svn.open-mpi.org/trac/ompi/ticket/542
an issue on Solaris where /usr/bin/grep doesn't understand -q. The
grep that AC_PROG_GREP finds (/usr/xpg4/bin/grep), which is POSIX
compliant and understands -q. Also fix one instance where egrep was
used instead of $EGREP.
This commit was SVN r14829.
