2004-01-15 09:08:25 +03:00
|
|
|
/*
|
2007-03-17 02:11:45 +03:00
|
|
|
* Copyright (c) 2004-2007 The Trustees of Indiana University and Indiana
|
2005-11-05 22:57:48 +03:00
|
|
|
* University Research and Technology
|
|
|
|
* Corporation. All rights reserved.
|
Deal with the ticket #1239 and #712. This will upgrade the Open MPI support
for the F90 type create functions to the requirements of MPI 2.1 standard.
Advice to implementors. An application may often repeat a call to
MPI_TYPE_CREATE_F90_xxxx with the same combination of (xxxx,p,r).
The application is not allowed to free the returned predefined, unnamed
datatype handles. To prevent the creation of a potentially huge amount of
handles, the MPI implementation should return the same datatype handle for
the same (REAL/COMPLEX/INTEGER,p,r) combination. Checking for the
combination (p,r) in the preceding call to MPI_TYPE_CREATE_F90_xxxx and
using a hash-table to find formerly generated handles should limit the
overhead of finding a previously generated datatype with same combination
of (xxxx,p,r). (End of advice to implementors.)
This commit fixes trac:1239, and #712.
This commit was SVN r19458.
The following Trac tickets were found above:
Ticket 1239 --> https://svn.open-mpi.org/trac/ompi/ticket/1239
2008-08-31 22:36:32 +04:00
|
|
|
* Copyright (c) 2004-2008 The University of Tennessee and The University
|
2005-11-05 22:57:48 +03:00
|
|
|
* of Tennessee Research Foundation. All rights
|
|
|
|
* reserved.
|
2004-11-28 23:09:25 +03:00
|
|
|
* Copyright (c) 2004-2005 High Performance Computing Center Stuttgart,
|
|
|
|
* University of Stuttgart. All rights reserved.
|
2005-03-24 15:43:37 +03:00
|
|
|
* Copyright (c) 2004-2005 The Regents of the University of California.
|
|
|
|
* All rights reserved.
|
2009-04-27 18:15:33 +04:00
|
|
|
* Copyright (c) 2006-2009 Cisco Systems, Inc. All rights reserved.
|
2007-02-09 23:17:37 +03:00
|
|
|
* Copyright (c) 2006-2007 Los Alamos National Security, LLC. All rights
|
2006-11-22 05:06:52 +03:00
|
|
|
* reserved.
|
2009-07-07 22:32:14 +04:00
|
|
|
* Copyright (c) 2006-2009 University of Houston. All rights reserved.
|
2009-02-24 20:17:33 +03:00
|
|
|
* Copyright (c) 2008-2009 Sun Microsystems, Inc. All rights reserved.
|
2006-11-22 05:06:52 +03:00
|
|
|
*
|
2004-11-22 04:38:40 +03:00
|
|
|
* $COPYRIGHT$
|
|
|
|
*
|
|
|
|
* Additional copyrights may follow
|
|
|
|
*
|
2004-01-15 09:08:25 +03:00
|
|
|
* $HEADER$
|
|
|
|
*/
|
|
|
|
|
2004-06-07 19:33:53 +04:00
|
|
|
#include "ompi_config.h"
|
2004-01-15 09:08:25 +03:00
|
|
|
|
2006-09-29 17:19:44 +04:00
|
|
|
#ifdef HAVE_SYS_TIME_H
|
|
|
|
#include <sys/time.h>
|
|
|
|
#endif /* HAVE_SYS_TIME_H */
|
2008-08-06 18:22:03 +04:00
|
|
|
#if HAVE_PTHREAD_H
|
|
|
|
#include <pthread.h>
|
|
|
|
#endif
|
2008-11-05 22:41:16 +03:00
|
|
|
#ifdef HAVE_UNISTD_H
|
|
|
|
#include <unistd.h>
|
|
|
|
#endif
|
2006-09-29 17:19:44 +04:00
|
|
|
|
2004-01-15 09:08:25 +03:00
|
|
|
#include "mpi.h"
|
2007-12-07 16:09:07 +03:00
|
|
|
#include "opal/class/opal_list.h"
|
2005-08-16 20:17:52 +04:00
|
|
|
#include "opal/mca/base/base.h"
|
|
|
|
#include "opal/mca/paffinity/base/base.h"
|
2005-08-26 14:56:39 +04:00
|
|
|
#include "opal/mca/maffinity/base/base.h"
|
2005-08-16 20:17:52 +04:00
|
|
|
#include "opal/runtime/opal_progress.h"
|
|
|
|
#include "opal/threads/threads.h"
|
2009-02-14 05:26:12 +03:00
|
|
|
#include "opal/util/output.h"
|
2008-06-19 17:48:26 +04:00
|
|
|
#include "opal/util/error.h"
|
2005-07-04 06:38:44 +04:00
|
|
|
#include "opal/util/stacktrace.h"
|
2008-05-20 01:57:54 +04:00
|
|
|
#include "opal/util/show_help.h"
|
2005-07-03 16:07:29 +04:00
|
|
|
#include "opal/runtime/opal.h"
|
|
|
|
#include "opal/event/event.h"
|
2004-01-15 09:08:25 +03:00
|
|
|
|
2005-08-16 20:17:52 +04:00
|
|
|
#include "orte/util/proc_info.h"
|
|
|
|
#include "orte/runtime/runtime.h"
|
2007-07-20 05:34:02 +04:00
|
|
|
#include "orte/mca/grpcomm/grpcomm.h"
|
2008-02-28 04:57:57 +03:00
|
|
|
#include "orte/runtime/orte_globals.h"
|
2008-06-09 18:53:58 +04:00
|
|
|
#include "orte/util/show_help.h"
|
2008-07-11 01:12:45 +04:00
|
|
|
#include "orte/mca/ess/ess.h"
|
2005-08-16 20:17:52 +04:00
|
|
|
|
2009-06-09 18:33:35 +04:00
|
|
|
#include "orte/mca/errmgr/errmgr.h"
|
|
|
|
#include "orte/util/name_fns.h"
|
|
|
|
|
2009-04-27 18:15:33 +04:00
|
|
|
#include "orte/mca/notifier/notifier.h"
|
|
|
|
|
2006-02-12 04:33:29 +03:00
|
|
|
#include "ompi/constants.h"
|
2005-11-22 18:24:39 +03:00
|
|
|
#include "ompi/mpi/f77/constants.h"
|
2005-08-16 20:17:52 +04:00
|
|
|
#include "ompi/runtime/mpiruntime.h"
|
|
|
|
#include "ompi/runtime/params.h"
|
2009-07-07 22:32:14 +04:00
|
|
|
#include "ompi/runtime/ompi_module_exchange.h"
|
2005-08-16 20:17:52 +04:00
|
|
|
#include "ompi/communicator/communicator.h"
|
|
|
|
#include "ompi/info/info.h"
|
|
|
|
#include "ompi/errhandler/errcode.h"
|
|
|
|
#include "ompi/request/request.h"
|
|
|
|
#include "ompi/op/op.h"
|
Two major things in this commit:
* New "op" MPI layer framework
* Addition of the MPI_REDUCE_LOCAL proposed function (for MPI-2.2)
= Op framework =
Add new "op" framework in the ompi layer. This framework replaces the
hard-coded MPI_Op back-end functions for (MPI_Op, MPI_Datatype) tuples
for pre-defined MPI_Ops, allowing components and modules to provide
the back-end functions. The intent is that components can be written
to take advantage of hardware acceleration (GPU, FPGA, specialized CPU
instructions, etc.). Similar to other frameworks, components are
intended to be able to discover at run-time if they can be used, and
if so, elect themselves to be selected (or disqualify themselves from
selection if they cannot run). If specialized hardware is not
available, there is a default set of functions that will automatically
be used.
This framework is ''not'' used for user-defined MPI_Ops.
The new op framework is similar to the existing coll framework, in
that the final set of function pointers that are used on any given
intrinsic MPI_Op can be a mixed bag of function pointers, potentially
coming from multiple different op modules. This allows for hardware
that only supports some of the operations, not all of them (e.g., a
GPU that only supports single-precision operations).
All the hard-coded back-end MPI_Op functions for (MPI_Op,
MPI_Datatype) tuples still exist, but unlike coll, they're in the
framework base (vs. being in a separate "basic" component) and are
automatically used if no component is found at runtime that provides a
module with the necessary function pointers.
There is an "example" op component that will hopefully be useful to
those writing meaningful op components. It is currently
.ompi_ignore'd so that it doesn't impinge on other developers (it's
somewhat chatty in terms of opal_output() so that you can tell when
its functions have been invoked). See the README file in the example
op component directory. Developers of new op components are
encouraged to look at the following wiki pages:
https://svn.open-mpi.org/trac/ompi/wiki/devel/Autogen
https://svn.open-mpi.org/trac/ompi/wiki/devel/CreateComponent
https://svn.open-mpi.org/trac/ompi/wiki/devel/CreateFramework
= MPI_REDUCE_LOCAL =
Part of the MPI-2.2 proposal listed here:
https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/24
is to add a new function named MPI_REDUCE_LOCAL. It is very easy to
implement, so I added it (also because it makes testing the op
framework pretty easy -- you can do it in serial rather than via
parallel reductions). There's even a man page!
This commit was SVN r20280.
2009-01-15 02:44:31 +03:00
|
|
|
#include "ompi/mca/op/op.h"
|
|
|
|
#include "ompi/mca/op/base/base.h"
|
2005-08-16 20:17:52 +04:00
|
|
|
#include "ompi/file/file.h"
|
|
|
|
#include "ompi/attribute/attribute.h"
|
|
|
|
#include "ompi/mca/allocator/base/base.h"
|
2005-09-13 02:28:23 +04:00
|
|
|
#include "ompi/mca/rcache/base/base.h"
|
|
|
|
#include "ompi/mca/rcache/rcache.h"
|
2005-08-16 20:17:52 +04:00
|
|
|
#include "ompi/mca/mpool/base/base.h"
|
|
|
|
#include "ompi/mca/pml/pml.h"
|
|
|
|
#include "ompi/mca/pml/base/base.h"
|
2006-01-28 18:38:37 +03:00
|
|
|
#include "ompi/mca/osc/base/base.h"
|
2005-08-16 20:17:52 +04:00
|
|
|
#include "ompi/mca/coll/base/base.h"
|
|
|
|
#include "ompi/mca/io/io.h"
|
|
|
|
#include "ompi/mca/io/base/base.h"
|
2005-09-01 00:35:15 +04:00
|
|
|
#include "ompi/debuggers/debuggers.h"
|
2005-09-13 00:25:01 +04:00
|
|
|
#include "ompi/proc/proc.h"
|
2007-07-17 04:06:35 +04:00
|
|
|
#include "ompi/mca/pml/base/pml_base_bsend.h"
|
2008-02-28 04:57:57 +03:00
|
|
|
#include "ompi/mca/dpm/base/base.h"
|
|
|
|
#include "ompi/mca/pubsub/base/base.h"
|
2005-08-16 20:17:52 +04:00
|
|
|
|
2007-03-17 02:11:45 +03:00
|
|
|
#if OPAL_ENABLE_FT == 1
|
|
|
|
#include "ompi/mca/crcp/crcp.h"
|
|
|
|
#include "ompi/mca/crcp/base/base.h"
|
|
|
|
#endif
|
|
|
|
#include "ompi/runtime/ompi_cr.h"
|
|
|
|
|
2008-03-18 12:39:07 +03:00
|
|
|
#include "orte/runtime/orte_globals.h"
|
2008-05-01 19:06:10 +04:00
|
|
|
|
Deal with the ticket #1239 and #712. This will upgrade the Open MPI support
for the F90 type create functions to the requirements of MPI 2.1 standard.
Advice to implementors. An application may often repeat a call to
MPI_TYPE_CREATE_F90_xxxx with the same combination of (xxxx,p,r).
The application is not allowed to free the returned predefined, unnamed
datatype handles. To prevent the creation of a potentially huge amount of
handles, the MPI implementation should return the same datatype handle for
the same (REAL/COMPLEX/INTEGER,p,r) combination. Checking for the
combination (p,r) in the preceding call to MPI_TYPE_CREATE_F90_xxxx and
using a hash-table to find formerly generated handles should limit the
overhead of finding a previously generated datatype with same combination
of (xxxx,p,r). (End of advice to implementors.)
This commit fixes trac:1239, and #712.
This commit was SVN r19458.
The following Trac tickets were found above:
Ticket 1239 --> https://svn.open-mpi.org/trac/ompi/ticket/1239
2008-08-31 22:36:32 +04:00
|
|
|
/* This is required for the boundaries of the hash tables used to store
|
|
|
|
* the F90 types returned by the MPI_Type_create_f90_XXX functions.
|
|
|
|
*/
|
|
|
|
#include <float.h>
|
|
|
|
|
2009-05-07 00:11:28 +04:00
|
|
|
#if OPAL_CC_USE_PRAGMA_IDENT
|
2008-05-01 19:06:10 +04:00
|
|
|
#pragma ident OMPI_IDENT_STRING
|
2009-05-07 00:11:28 +04:00
|
|
|
#elif OPAL_CC_USE_IDENT
|
2008-05-01 19:06:10 +04:00
|
|
|
#ident OMPI_IDENT_STRING
|
|
|
|
#endif
|
|
|
|
const char ompi_version_string[] = OMPI_IDENT_STRING;
|
|
|
|
|
2004-02-05 04:52:56 +03:00
|
|
|
/*
|
|
|
|
* Global variables and symbols for the MPI layer
|
|
|
|
*/
|
|
|
|
|
2004-06-07 19:33:53 +04:00
|
|
|
bool ompi_mpi_initialized = false;
|
|
|
|
bool ompi_mpi_finalized = false;
|
2004-08-12 20:56:24 +04:00
|
|
|
|
2004-06-07 19:33:53 +04:00
|
|
|
bool ompi_mpi_thread_multiple = false;
|
|
|
|
int ompi_mpi_thread_requested = MPI_THREAD_SINGLE;
|
|
|
|
int ompi_mpi_thread_provided = MPI_THREAD_SINGLE;
|
2004-02-05 04:52:56 +03:00
|
|
|
|
2005-07-04 02:45:48 +04:00
|
|
|
opal_thread_t *ompi_mpi_main_thread = NULL;
|
2004-11-15 23:03:14 +03:00
|
|
|
|
2005-08-26 14:56:39 +04:00
|
|
|
bool ompi_mpi_maffinity_setup = false;
|
|
|
|
|
2008-08-06 21:29:41 +04:00
|
|
|
bool ompi_warn_on_fork;
|
2008-08-06 18:22:03 +04:00
|
|
|
|
2009-05-07 00:11:28 +04:00
|
|
|
#if OPAL_HAVE_POSIX_THREADS
|
2008-08-06 18:22:03 +04:00
|
|
|
static bool fork_warning_issued = false;
|
2008-08-06 21:29:41 +04:00
|
|
|
static bool atfork_called = false;
|
2008-08-06 18:22:03 +04:00
|
|
|
|
2008-08-06 21:29:41 +04:00
|
|
|
static void warn_fork_cb(void)
|
2008-08-06 18:22:03 +04:00
|
|
|
{
|
|
|
|
if (ompi_mpi_initialized && !ompi_mpi_finalized && !fork_warning_issued) {
|
2008-08-06 21:29:41 +04:00
|
|
|
orte_show_help("help-mpi-runtime.txt", "mpi_init:warn-fork", true,
|
2009-03-06 00:56:03 +03:00
|
|
|
orte_process_info.nodename, getpid(),
|
2009-02-24 20:17:33 +03:00
|
|
|
ompi_mpi_comm_world.comm.c_my_rank);
|
2008-08-06 18:22:03 +04:00
|
|
|
fork_warning_issued = true;
|
|
|
|
}
|
|
|
|
}
|
2008-08-06 21:29:41 +04:00
|
|
|
#endif
|
2008-08-06 18:22:03 +04:00
|
|
|
|
|
|
|
void ompi_warn_fork(void)
|
|
|
|
{
|
2009-05-07 00:11:28 +04:00
|
|
|
#if OPAL_HAVE_POSIX_THREADS
|
2008-08-06 21:29:41 +04:00
|
|
|
if (ompi_warn_on_fork && !atfork_called) {
|
|
|
|
pthread_atfork(warn_fork_cb, NULL, NULL);
|
|
|
|
atfork_called = true;
|
2008-08-06 18:22:03 +04:00
|
|
|
}
|
|
|
|
#endif
|
|
|
|
}
|
|
|
|
|
2005-11-22 18:24:39 +03:00
|
|
|
/*
|
|
|
|
* These variables are here, rather than under ompi/mpi/c/foo.c
|
|
|
|
* because it is not sufficient to have a .c file that only contains
|
|
|
|
* variables -- you must have a function that is invoked from
|
|
|
|
* elsewhere in the code to guarantee that all linkers will pull in
|
|
|
|
* the .o file from the library. Hence, although these are MPI
|
|
|
|
* constants, we might as well just define them here (i.e., in a file
|
|
|
|
* that already has a function that is guaranteed to be linked in,
|
|
|
|
* rather than make a new .c file with the constants and a
|
|
|
|
* corresponding dummy function that is invoked from this function).
|
|
|
|
*
|
Clean up the Fortran MPI sentinel values per problem reported on the
users mailing list:
http://www.open-mpi.org/community/lists/users/2006/07/1680.php
Warning: this log message is not for the weak. Read at your own
risk.
The problem was that we had several variables in Fortran common blocks
of various types, but their C counterparts were all of a type
equivalent to a fortran double complex. This didn't seem to matter
for the compilers that we tested, but we never tested static builds
(which is where this problem seems to occur, at least with the Intel
compiler: the linker compilains that the variable in the common block
in the user's .o file was of one size/alignment but the one in the C
library was a different size/alignment).
So this patch fixes the sizes/types of the Fortran common block
variables and their corresponding C instantiations to be of the same
sizes/types.
But wait, there's more.
We recently introduced a fix for the OSX linker where some C versions
of the fortran common block variables (e.g.,
_ompi_fortran_status_ignore) were not being found when linking
ompi_info (!). Further research shows that the code path for
ompi_info to require ompi_fortran_status_ignore is, unfortunately,
necessary (a quirk of how various components pull in different
portions of the code base -- nothing in ompi_info itself requires
fortran or MPI knowledge, of course).
Hence, the real problem was that there was no code path from ompi_info
to the portion of the code base where the C globals corresponding to
the Fortran common block variables were instantiated. This is because
the OSX linker does not automatically pull in .o files that only
contain unintialized global variables; the OSX linker typically only
pulls in a .o file from a library if it either has a function that is
used or have a global variable that is initialized (that's the short
version; lots of details and corner cases omitted). Hence, we changed
the global C variables corresponding to the fortran common blocks to
be initialized, thereby causing the OSX linker to pull them in
automatically -- problem solved. At the same time, we moved the
constants to another .c file with a function, just for good measure.
However, this didn't really solve the problem:
1. The function in the file with the C versions of the fortran common
block variables (ompi/mpi/f77/test_constants_f.c) did not have a
code path that was reachable from ompi_info, so the only reason
that the constants were found (on OSX) was because they were
initialized in the global scope (i.e., causing the OSX compiler to
pull in that .o file).
2. Initializing these variable in the global scope causes problems for
some linkers where -- once all the size/type problems mentioned
above were fixed -- the alignments of fortran common blocks and C
global variables do not match (even though the types of the Fortran
and C variables match -- wow!). Hence, initializing the C
variables would not necessarily match the alignment of what Fortran
expected, and the linker would issue a warning (i.e., the alignment
warnings referenced in the original post).
The solution is two-fold:
1. Move the Fortran variables from test_constants_f.c to
ompi/mpi/runtime/ompi_mpi_init.c where there are other global
constants that *are* initialized (that had nothing to do with
fortran, so the alignment issues described above are not a factor),
and therefore all linkers (including the OSX linker) will pull in
this .o file and find all the symbols that it needs.
2. Do not initialize the C variables corresponding to the Fortran
common blocks in the global scope. Indeed, never initialize them
at all (because we never need their *values* - we only check for
their *locations*). Since nothing is ever written to these
variables (particularly in the global scope), the linker does not
see any alignment differences during initialization, but does make
both the C and Fortran variables have the same addresses (this
method has been working in LAM/MPI for over a decade).
There were some comments here in the OMPI code base and in the LAM
code base that stated/implied that C variables corresponding to
Fortran common blocks had to have the same alignment as the Fortran
common blocks (i.e., 16). There were attempts in both code bases to
ensure that this was true. However, the attempts were wrong (in both
code bases), and I have now read enough Fortran compiler documentation
to convince myself that matching alignments is not required (indeed,
it's beyond our control). As long as C variables corresponding to
Fortran common blocks are not initialized in the global scope, the
linker will "figure it out" and adjust the alignment to whatever is
required (i.e., the greater of the alignments). Specifically (to
counter comments that no longer exist in the OMPI code base but still
exist in the LAM code base):
- there is no need to make attempts to specially align C variables
corresponding to Fortran common blocks
- the types and sizes of C variables corresponding to Fortran common
blocks should match, but do not need to be on any particular
alignment
Finally, as a side effect of this effort, I found a bunch of
inconsistencies with the intent of status/array_of_statuses
parameters. For all the functions that I modified they should be
"out" (not inout).
This commit was SVN r11057.
2006-07-31 19:07:09 +04:00
|
|
|
* Additionally, there can be/are strange linking paths such that
|
2006-09-19 11:55:41 +04:00
|
|
|
* ompi_info needs symbols such as ompi_fortran_status_ignore,
|
Clean up the Fortran MPI sentinel values per problem reported on the
users mailing list:
http://www.open-mpi.org/community/lists/users/2006/07/1680.php
Warning: this log message is not for the weak. Read at your own
risk.
The problem was that we had several variables in Fortran common blocks
of various types, but their C counterparts were all of a type
equivalent to a fortran double complex. This didn't seem to matter
for the compilers that we tested, but we never tested static builds
(which is where this problem seems to occur, at least with the Intel
compiler: the linker compilains that the variable in the common block
in the user's .o file was of one size/alignment but the one in the C
library was a different size/alignment).
So this patch fixes the sizes/types of the Fortran common block
variables and their corresponding C instantiations to be of the same
sizes/types.
But wait, there's more.
We recently introduced a fix for the OSX linker where some C versions
of the fortran common block variables (e.g.,
_ompi_fortran_status_ignore) were not being found when linking
ompi_info (!). Further research shows that the code path for
ompi_info to require ompi_fortran_status_ignore is, unfortunately,
necessary (a quirk of how various components pull in different
portions of the code base -- nothing in ompi_info itself requires
fortran or MPI knowledge, of course).
Hence, the real problem was that there was no code path from ompi_info
to the portion of the code base where the C globals corresponding to
the Fortran common block variables were instantiated. This is because
the OSX linker does not automatically pull in .o files that only
contain unintialized global variables; the OSX linker typically only
pulls in a .o file from a library if it either has a function that is
used or have a global variable that is initialized (that's the short
version; lots of details and corner cases omitted). Hence, we changed
the global C variables corresponding to the fortran common blocks to
be initialized, thereby causing the OSX linker to pull them in
automatically -- problem solved. At the same time, we moved the
constants to another .c file with a function, just for good measure.
However, this didn't really solve the problem:
1. The function in the file with the C versions of the fortran common
block variables (ompi/mpi/f77/test_constants_f.c) did not have a
code path that was reachable from ompi_info, so the only reason
that the constants were found (on OSX) was because they were
initialized in the global scope (i.e., causing the OSX compiler to
pull in that .o file).
2. Initializing these variable in the global scope causes problems for
some linkers where -- once all the size/type problems mentioned
above were fixed -- the alignments of fortran common blocks and C
global variables do not match (even though the types of the Fortran
and C variables match -- wow!). Hence, initializing the C
variables would not necessarily match the alignment of what Fortran
expected, and the linker would issue a warning (i.e., the alignment
warnings referenced in the original post).
The solution is two-fold:
1. Move the Fortran variables from test_constants_f.c to
ompi/mpi/runtime/ompi_mpi_init.c where there are other global
constants that *are* initialized (that had nothing to do with
fortran, so the alignment issues described above are not a factor),
and therefore all linkers (including the OSX linker) will pull in
this .o file and find all the symbols that it needs.
2. Do not initialize the C variables corresponding to the Fortran
common blocks in the global scope. Indeed, never initialize them
at all (because we never need their *values* - we only check for
their *locations*). Since nothing is ever written to these
variables (particularly in the global scope), the linker does not
see any alignment differences during initialization, but does make
both the C and Fortran variables have the same addresses (this
method has been working in LAM/MPI for over a decade).
There were some comments here in the OMPI code base and in the LAM
code base that stated/implied that C variables corresponding to
Fortran common blocks had to have the same alignment as the Fortran
common blocks (i.e., 16). There were attempts in both code bases to
ensure that this was true. However, the attempts were wrong (in both
code bases), and I have now read enough Fortran compiler documentation
to convince myself that matching alignments is not required (indeed,
it's beyond our control). As long as C variables corresponding to
Fortran common blocks are not initialized in the global scope, the
linker will "figure it out" and adjust the alignment to whatever is
required (i.e., the greater of the alignments). Specifically (to
counter comments that no longer exist in the OMPI code base but still
exist in the LAM code base):
- there is no need to make attempts to specially align C variables
corresponding to Fortran common blocks
- the types and sizes of C variables corresponding to Fortran common
blocks should match, but do not need to be on any particular
alignment
Finally, as a side effect of this effort, I found a bunch of
inconsistencies with the intent of status/array_of_statuses
parameters. For all the functions that I modified they should be
"out" (not inout).
This commit was SVN r11057.
2006-07-31 19:07:09 +04:00
|
|
|
* which, if they weren't here with a collection of other global
|
|
|
|
* symbols that are initialized (which seems to force this .o file to
|
|
|
|
* be pulled into the resolution process, because ompi_info certainly
|
|
|
|
* does not call ompi_mpi_init()), would not be able to be found by
|
|
|
|
* the OSX linker.
|
|
|
|
*
|
2005-11-22 18:24:39 +03:00
|
|
|
* NOTE: See the big comment in ompi/mpi/f77/constants.h about why we
|
|
|
|
* have four symbols for each of the common blocks (e.g., the Fortran
|
|
|
|
* equivalent(s) of MPI_STATUS_IGNORE). Here, we can only have *one*
|
|
|
|
* value (not four). So the only thing we can do is make it equal to
|
|
|
|
* the fortran compiler convention that was selected at configure
|
|
|
|
* time. Note that this is also true for the value of .TRUE. from the
|
|
|
|
* Fortran compiler, so even though Open MPI supports all four Fortran
|
|
|
|
* symbol conventions, it can only support one convention for the two
|
|
|
|
* C constants (MPI_FORTRAN_STATUS[ES]_IGNORE) and only support one
|
|
|
|
* compiler for the value of .TRUE. Ugh!!
|
|
|
|
*
|
|
|
|
* Note that the casts here are ok -- we're *only* comparing pointer
|
|
|
|
* values (i.e., they'll never be de-referenced). The global symbols
|
|
|
|
* are actually of type (ompi_fortran_common_t) (for alignment
|
|
|
|
* issues), but MPI says that MPI_F_STATUS[ES]_IGNORE must be of type
|
|
|
|
* (MPI_Fint*). Hence, we have to cast to make compilers not
|
|
|
|
* complain.
|
|
|
|
*/
|
2005-11-23 00:52:14 +03:00
|
|
|
#if OMPI_WANT_F77_BINDINGS
|
|
|
|
# if OMPI_F77_CAPS
|
2005-11-22 18:24:39 +03:00
|
|
|
MPI_Fint *MPI_F_STATUS_IGNORE = (MPI_Fint*) &MPI_FORTRAN_STATUS_IGNORE;
|
|
|
|
MPI_Fint *MPI_F_STATUSES_IGNORE = (MPI_Fint*) &MPI_FORTRAN_STATUSES_IGNORE;
|
2005-11-23 00:52:14 +03:00
|
|
|
# elif OMPI_F77_PLAIN
|
2005-11-22 18:24:39 +03:00
|
|
|
MPI_Fint *MPI_F_STATUS_IGNORE = (MPI_Fint*) &mpi_fortran_status_ignore;
|
|
|
|
MPI_Fint *MPI_F_STATUSES_IGNORE = (MPI_Fint*) &mpi_fortran_statuses_ignore;
|
2005-11-23 00:52:14 +03:00
|
|
|
# elif OMPI_F77_SINGLE_UNDERSCORE
|
2005-11-22 18:24:39 +03:00
|
|
|
MPI_Fint *MPI_F_STATUS_IGNORE = (MPI_Fint*) &mpi_fortran_status_ignore_;
|
|
|
|
MPI_Fint *MPI_F_STATUSES_IGNORE = (MPI_Fint*) &mpi_fortran_statuses_ignore_;
|
2005-11-23 00:52:14 +03:00
|
|
|
# elif OMPI_F77_DOUBLE_UNDERSCORE
|
2005-11-22 18:24:39 +03:00
|
|
|
MPI_Fint *MPI_F_STATUS_IGNORE = (MPI_Fint*) &mpi_fortran_status_ignore__;
|
|
|
|
MPI_Fint *MPI_F_STATUSES_IGNORE = (MPI_Fint*) &mpi_fortran_statuses_ignore__;
|
2005-11-23 00:52:14 +03:00
|
|
|
# else
|
|
|
|
# error Unrecognized Fortran 77 name mangling scheme
|
|
|
|
# endif
|
2005-11-22 18:24:39 +03:00
|
|
|
#else
|
2005-11-23 00:52:14 +03:00
|
|
|
MPI_Fint *MPI_F_STATUS_IGNORE = NULL;
|
|
|
|
MPI_Fint *MPI_F_STATUSES_IGNORE = NULL;
|
|
|
|
#endif /* OMPI_WANT_F77_BINDINGS */
|
2005-11-22 18:24:39 +03:00
|
|
|
|
2005-08-26 14:56:39 +04:00
|
|
|
|
Clean up the Fortran MPI sentinel values per problem reported on the
users mailing list:
http://www.open-mpi.org/community/lists/users/2006/07/1680.php
Warning: this log message is not for the weak. Read at your own
risk.
The problem was that we had several variables in Fortran common blocks
of various types, but their C counterparts were all of a type
equivalent to a fortran double complex. This didn't seem to matter
for the compilers that we tested, but we never tested static builds
(which is where this problem seems to occur, at least with the Intel
compiler: the linker compilains that the variable in the common block
in the user's .o file was of one size/alignment but the one in the C
library was a different size/alignment).
So this patch fixes the sizes/types of the Fortran common block
variables and their corresponding C instantiations to be of the same
sizes/types.
But wait, there's more.
We recently introduced a fix for the OSX linker where some C versions
of the fortran common block variables (e.g.,
_ompi_fortran_status_ignore) were not being found when linking
ompi_info (!). Further research shows that the code path for
ompi_info to require ompi_fortran_status_ignore is, unfortunately,
necessary (a quirk of how various components pull in different
portions of the code base -- nothing in ompi_info itself requires
fortran or MPI knowledge, of course).
Hence, the real problem was that there was no code path from ompi_info
to the portion of the code base where the C globals corresponding to
the Fortran common block variables were instantiated. This is because
the OSX linker does not automatically pull in .o files that only
contain unintialized global variables; the OSX linker typically only
pulls in a .o file from a library if it either has a function that is
used or have a global variable that is initialized (that's the short
version; lots of details and corner cases omitted). Hence, we changed
the global C variables corresponding to the fortran common blocks to
be initialized, thereby causing the OSX linker to pull them in
automatically -- problem solved. At the same time, we moved the
constants to another .c file with a function, just for good measure.
However, this didn't really solve the problem:
1. The function in the file with the C versions of the fortran common
block variables (ompi/mpi/f77/test_constants_f.c) did not have a
code path that was reachable from ompi_info, so the only reason
that the constants were found (on OSX) was because they were
initialized in the global scope (i.e., causing the OSX compiler to
pull in that .o file).
2. Initializing these variable in the global scope causes problems for
some linkers where -- once all the size/type problems mentioned
above were fixed -- the alignments of fortran common blocks and C
global variables do not match (even though the types of the Fortran
and C variables match -- wow!). Hence, initializing the C
variables would not necessarily match the alignment of what Fortran
expected, and the linker would issue a warning (i.e., the alignment
warnings referenced in the original post).
The solution is two-fold:
1. Move the Fortran variables from test_constants_f.c to
ompi/mpi/runtime/ompi_mpi_init.c where there are other global
constants that *are* initialized (that had nothing to do with
fortran, so the alignment issues described above are not a factor),
and therefore all linkers (including the OSX linker) will pull in
this .o file and find all the symbols that it needs.
2. Do not initialize the C variables corresponding to the Fortran
common blocks in the global scope. Indeed, never initialize them
at all (because we never need their *values* - we only check for
their *locations*). Since nothing is ever written to these
variables (particularly in the global scope), the linker does not
see any alignment differences during initialization, but does make
both the C and Fortran variables have the same addresses (this
method has been working in LAM/MPI for over a decade).
There were some comments here in the OMPI code base and in the LAM
code base that stated/implied that C variables corresponding to
Fortran common blocks had to have the same alignment as the Fortran
common blocks (i.e., 16). There were attempts in both code bases to
ensure that this was true. However, the attempts were wrong (in both
code bases), and I have now read enough Fortran compiler documentation
to convince myself that matching alignments is not required (indeed,
it's beyond our control). As long as C variables corresponding to
Fortran common blocks are not initialized in the global scope, the
linker will "figure it out" and adjust the alignment to whatever is
required (i.e., the greater of the alignments). Specifically (to
counter comments that no longer exist in the OMPI code base but still
exist in the LAM code base):
- there is no need to make attempts to specially align C variables
corresponding to Fortran common blocks
- the types and sizes of C variables corresponding to Fortran common
blocks should match, but do not need to be on any particular
alignment
Finally, as a side effect of this effort, I found a bunch of
inconsistencies with the intent of status/array_of_statuses
parameters. For all the functions that I modified they should be
"out" (not inout).
This commit was SVN r11057.
2006-07-31 19:07:09 +04:00
|
|
|
/* Constants for the Fortran layer. These values are referred to via
|
|
|
|
common blocks in the Fortran equivalents. See
|
|
|
|
ompi/mpi/f77/constants.h for a more detailed explanation.
|
|
|
|
|
|
|
|
The values are *NOT* initialized. We do not use the values of
|
|
|
|
these constants; only their addresses (because they're always
|
|
|
|
passed by reference by Fortran).
|
|
|
|
|
|
|
|
Initializing upon instantiation these can reveal size and/or
|
|
|
|
alignment differences between Fortran and C (!) which can cause
|
|
|
|
warnings or errors upon linking (e.g., making static libraries with
|
|
|
|
the intel 9.0 compilers on 64 bit platforms shows alignment
|
|
|
|
differences between libmpi.a and the user's application, resulting
|
|
|
|
in a linker warning). FWIW, if you initialize these variables in
|
|
|
|
functions (i.e., not at the instantiation in the global scope), the
|
|
|
|
linker somehow "figures it all out" (w.r.t. different alignments
|
|
|
|
between fortan common blocks and the corresponding C variables) and
|
|
|
|
no linker warnings occur.
|
|
|
|
|
|
|
|
Note that the rationale for the types of each of these variables is
|
|
|
|
discussed in ompi/include/mpif-common.h. Do not change the types
|
|
|
|
without also modifying ompi/mpi/f77/constants.h and
|
|
|
|
ompi/include/mpif-common.h.
|
|
|
|
*/
|
|
|
|
|
|
|
|
#define INST(type, upper_case, lower_case, single_u, double_u) \
|
|
|
|
type lower_case; \
|
|
|
|
type upper_case; \
|
|
|
|
type single_u; \
|
|
|
|
type double_u
|
|
|
|
|
|
|
|
INST(int, MPI_FORTRAN_BOTTOM, mpi_fortran_bottom,
|
|
|
|
mpi_fortran_bottom_, mpi_fortran_bottom__);
|
|
|
|
INST(int, MPI_FORTRAN_IN_PLACE, mpi_fortran_in_place,
|
|
|
|
mpi_fortran_in_place_, mpi_fortran_in_place__);
|
|
|
|
INST(char *, MPI_FORTRAN_ARGV_NULL, mpi_fortran_argv_null,
|
|
|
|
mpi_fortran_argv_null_, mpi_fortran_argv_null__);
|
|
|
|
INST(double, MPI_FORTRAN_ARGVS_NULL, mpi_fortran_argvs_null,
|
|
|
|
mpi_fortran_argvs_null_, mpi_fortran_argvs_null__);
|
|
|
|
INST(int *, MPI_FORTRAN_ERRCODES_IGNORE, mpi_fortran_errcodes_ignore,
|
|
|
|
mpi_fortran_errcodes_ignore_, mpi_fortran_errcodes_ignore__);
|
|
|
|
INST(int *, MPI_FORTRAN_STATUS_IGNORE, mpi_fortran_status_ignore,
|
|
|
|
mpi_fortran_status_ignore_, mpi_fortran_status_ignore__);
|
|
|
|
INST (double, MPI_FORTRAN_STATUSES_IGNORE, mpi_fortran_statuses_ignore,
|
|
|
|
mpi_fortran_statuses_ignore_, mpi_fortran_statuses_ignore__);
|
|
|
|
|
2008-08-31 23:56:39 +04:00
|
|
|
/*
|
|
|
|
* Hash tables for MPI_Type_create_f90* functions
|
|
|
|
*/
|
|
|
|
opal_hash_table_t ompi_mpi_f90_integer_hashtable;
|
|
|
|
opal_hash_table_t ompi_mpi_f90_real_hashtable;
|
|
|
|
opal_hash_table_t ompi_mpi_f90_complex_hashtable;
|
|
|
|
|
2007-12-07 16:09:07 +03:00
|
|
|
/*
|
|
|
|
* Per MPI-2:9.5.3, MPI_REGISTER_DATAREP is a memory leak. There is
|
|
|
|
* no way to *de*register datareps once they've been registered. So
|
|
|
|
* we have to track all registrations here so that they can be
|
|
|
|
* de-registered during MPI_FINALIZE so that memory-tracking debuggers
|
|
|
|
* don't show Open MPI as leaking memory.
|
|
|
|
*/
|
|
|
|
opal_list_t ompi_registered_datareps;
|
|
|
|
|
Clean up the Fortran MPI sentinel values per problem reported on the
users mailing list:
http://www.open-mpi.org/community/lists/users/2006/07/1680.php
Warning: this log message is not for the weak. Read at your own
risk.
The problem was that we had several variables in Fortran common blocks
of various types, but their C counterparts were all of a type
equivalent to a fortran double complex. This didn't seem to matter
for the compilers that we tested, but we never tested static builds
(which is where this problem seems to occur, at least with the Intel
compiler: the linker compilains that the variable in the common block
in the user's .o file was of one size/alignment but the one in the C
library was a different size/alignment).
So this patch fixes the sizes/types of the Fortran common block
variables and their corresponding C instantiations to be of the same
sizes/types.
But wait, there's more.
We recently introduced a fix for the OSX linker where some C versions
of the fortran common block variables (e.g.,
_ompi_fortran_status_ignore) were not being found when linking
ompi_info (!). Further research shows that the code path for
ompi_info to require ompi_fortran_status_ignore is, unfortunately,
necessary (a quirk of how various components pull in different
portions of the code base -- nothing in ompi_info itself requires
fortran or MPI knowledge, of course).
Hence, the real problem was that there was no code path from ompi_info
to the portion of the code base where the C globals corresponding to
the Fortran common block variables were instantiated. This is because
the OSX linker does not automatically pull in .o files that only
contain unintialized global variables; the OSX linker typically only
pulls in a .o file from a library if it either has a function that is
used or have a global variable that is initialized (that's the short
version; lots of details and corner cases omitted). Hence, we changed
the global C variables corresponding to the fortran common blocks to
be initialized, thereby causing the OSX linker to pull them in
automatically -- problem solved. At the same time, we moved the
constants to another .c file with a function, just for good measure.
However, this didn't really solve the problem:
1. The function in the file with the C versions of the fortran common
block variables (ompi/mpi/f77/test_constants_f.c) did not have a
code path that was reachable from ompi_info, so the only reason
that the constants were found (on OSX) was because they were
initialized in the global scope (i.e., causing the OSX compiler to
pull in that .o file).
2. Initializing these variable in the global scope causes problems for
some linkers where -- once all the size/type problems mentioned
above were fixed -- the alignments of fortran common blocks and C
global variables do not match (even though the types of the Fortran
and C variables match -- wow!). Hence, initializing the C
variables would not necessarily match the alignment of what Fortran
expected, and the linker would issue a warning (i.e., the alignment
warnings referenced in the original post).
The solution is two-fold:
1. Move the Fortran variables from test_constants_f.c to
ompi/mpi/runtime/ompi_mpi_init.c where there are other global
constants that *are* initialized (that had nothing to do with
fortran, so the alignment issues described above are not a factor),
and therefore all linkers (including the OSX linker) will pull in
this .o file and find all the symbols that it needs.
2. Do not initialize the C variables corresponding to the Fortran
common blocks in the global scope. Indeed, never initialize them
at all (because we never need their *values* - we only check for
their *locations*). Since nothing is ever written to these
variables (particularly in the global scope), the linker does not
see any alignment differences during initialization, but does make
both the C and Fortran variables have the same addresses (this
method has been working in LAM/MPI for over a decade).
There were some comments here in the OMPI code base and in the LAM
code base that stated/implied that C variables corresponding to
Fortran common blocks had to have the same alignment as the Fortran
common blocks (i.e., 16). There were attempts in both code bases to
ensure that this was true. However, the attempts were wrong (in both
code bases), and I have now read enough Fortran compiler documentation
to convince myself that matching alignments is not required (indeed,
it's beyond our control). As long as C variables corresponding to
Fortran common blocks are not initialized in the global scope, the
linker will "figure it out" and adjust the alignment to whatever is
required (i.e., the greater of the alignments). Specifically (to
counter comments that no longer exist in the OMPI code base but still
exist in the LAM code base):
- there is no need to make attempts to specially align C variables
corresponding to Fortran common blocks
- the types and sizes of C variables corresponding to Fortran common
blocks should match, but do not need to be on any particular
alignment
Finally, as a side effect of this effort, I found a bunch of
inconsistencies with the intent of status/array_of_statuses
parameters. For all the functions that I modified they should be
"out" (not inout).
This commit was SVN r11057.
2006-07-31 19:07:09 +04:00
|
|
|
|
2004-06-07 19:33:53 +04:00
|
|
|
int ompi_mpi_init(int argc, char **argv, int requested, int *provided)
|
2004-01-15 09:08:25 +03:00
|
|
|
{
|
2005-05-24 02:06:50 +04:00
|
|
|
int ret;
|
2004-06-07 19:33:53 +04:00
|
|
|
ompi_proc_t** procs;
|
2004-03-03 19:44:41 +03:00
|
|
|
size_t nprocs;
|
2004-11-17 05:30:07 +03:00
|
|
|
char *error = NULL;
|
2006-09-29 17:19:44 +04:00
|
|
|
bool timing = false;
|
|
|
|
int param, value;
|
2006-11-03 19:04:40 +03:00
|
|
|
struct timeval ompistart, ompistop;
|
2008-03-26 17:54:09 +03:00
|
|
|
char *event_val = NULL;
|
2009-05-12 06:18:35 +04:00
|
|
|
opal_paffinity_base_cpu_set_t mask;
|
2009-06-09 18:33:35 +04:00
|
|
|
bool proc_bound;
|
2007-02-07 17:22:37 +03:00
|
|
|
#if 0
|
|
|
|
/* see comment below about sched_yield */
|
2007-02-01 22:31:44 +03:00
|
|
|
int num_processors;
|
2007-02-07 17:22:37 +03:00
|
|
|
#endif
|
2008-05-20 01:57:54 +04:00
|
|
|
bool orte_setup = false;
|
2008-07-11 01:12:45 +04:00
|
|
|
bool paffinity_enabled = false;
|
2005-03-25 06:06:06 +03:00
|
|
|
|
2009-07-07 22:32:14 +04:00
|
|
|
/* bitflag of the thread level support provided. To be used
|
|
|
|
* for the modex in order to work in heterogeneous environments. */
|
|
|
|
uint8_t threadlevel_bf;
|
|
|
|
|
2008-03-25 20:18:17 +03:00
|
|
|
/* Setup enough to check get/set MCA params */
|
|
|
|
|
|
|
|
if (ORTE_SUCCESS != (ret = opal_init_util())) {
|
|
|
|
error = "ompi_mpi_init: opal_init_util failed";
|
2005-05-23 18:50:52 +04:00
|
|
|
goto error;
|
|
|
|
}
|
2005-08-16 20:17:52 +04:00
|
|
|
|
2008-03-25 20:18:17 +03:00
|
|
|
/* _After_ opal_init_util() but _before_ orte_init(), we need to
|
|
|
|
set an MCA param that tells libevent that it's ok to use any
|
2008-03-26 17:54:09 +03:00
|
|
|
mechanism in libevent that is available on this platform (e.g.,
|
2008-03-25 20:18:17 +03:00
|
|
|
epoll and friends). Per opal/event/event.s, we default to
|
|
|
|
select/poll -- but we know that MPI processes won't be using
|
|
|
|
pty's with the event engine, so it's ok to relax this
|
|
|
|
constraint and let any fd-monitoring mechanism be used. */
|
|
|
|
ret = mca_base_param_reg_string_name("opal", "event_include",
|
|
|
|
"Internal orted MCA param: tell opal_init() to use a specific mechanism in libevent",
|
2008-03-26 17:54:09 +03:00
|
|
|
false, false, "all", &event_val);
|
2008-03-25 20:18:17 +03:00
|
|
|
if (ret >= 0) {
|
|
|
|
/* We have to explicitly "set" the MCA param value here
|
|
|
|
because libevent initialization will re-register the MCA
|
|
|
|
param and therefore override the default. Setting the value
|
|
|
|
here puts the desired value ("all") in different storage
|
|
|
|
that is not overwritten if/when the MCA param is
|
2008-03-26 17:54:09 +03:00
|
|
|
re-registered. This is unless the user has specified a different
|
|
|
|
value for this MCA parameter. Make sure we check to see if the
|
|
|
|
default is specified before forcing "all" in case that is not what
|
|
|
|
the user desires. Note that we do *NOT* set this value as an
|
2008-03-25 20:18:17 +03:00
|
|
|
environment variable, just so that it won't be inherited by
|
|
|
|
any spawned processes and potentially cause unintented
|
|
|
|
side-effects with launching ORTE tools... */
|
2008-03-26 22:10:02 +03:00
|
|
|
if (0 == strcmp("all", event_val)) {
|
2008-03-26 17:54:09 +03:00
|
|
|
mca_base_param_set_string(ret, "all");
|
|
|
|
}
|
2008-03-25 20:18:17 +03:00
|
|
|
}
|
2008-03-26 17:54:09 +03:00
|
|
|
|
|
|
|
if( NULL != event_val ) {
|
|
|
|
free(event_val);
|
|
|
|
event_val = NULL;
|
|
|
|
}
|
|
|
|
|
2006-09-29 17:19:44 +04:00
|
|
|
/* check to see if we want timing information */
|
Bring the timing instrumentation to the trunk.
If you want to look at our launch and MPI process startup times, you can do so with two MCA params:
OMPI_MCA_orte_timing: set it to anything non-zero and you will get the launch time for different steps in the job launch procedure. The degree of detail depends on the launch environment. rsh will provide you with the average, min, and max launch time for the daemons. SLURM block launches the daemon, so you only get the time to launch the daemons and the total time to launch the job. Ditto for bproc. TM looks more like rsh. Only those four environments are currently supported - anyone interested in extending this capability to other environs is welcome to do so. In all cases, you also get the time to setup the job for launch.
OMPI_MCA_ompi_timing: set it to anything non-zero and you will get the time for mpi_init to reach the compound registry command, the time to execute that command, the time to go from our stage1 barrier to the stage2 barrier, and the time to go from the stage2 barrier to the end of mpi_init. This will be output for each process, so you'll have to compile any statistics on your own. Note: if someone develops a nice parser to do so, it would be really appreciated if you could/would share!
This commit was SVN r12302.
2006-10-25 19:27:47 +04:00
|
|
|
param = mca_base_param_reg_int_name("ompi", "timing",
|
2006-09-29 17:19:44 +04:00
|
|
|
"Request that critical timing loops be measured",
|
|
|
|
false, false, 0, &value);
|
|
|
|
if (value != 0) {
|
|
|
|
timing = true;
|
2006-11-03 19:04:40 +03:00
|
|
|
gettimeofday(&ompistart, NULL);
|
2006-09-29 17:19:44 +04:00
|
|
|
}
|
|
|
|
|
2009-05-04 15:07:40 +04:00
|
|
|
/* Setup ORTE - note that we are an MPI process */
|
|
|
|
if (ORTE_SUCCESS != (ret = orte_init(ORTE_PROC_MPI))) {
|
These changes were mostly captured in a prior RFC (except for #2 below) and are aimed specifically at improving startup performance and setting up the remaining modifications described in that RFC.
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.
2007-10-05 23:48:23 +04:00
|
|
|
error = "ompi_mpi_init: orte_init failed";
|
2005-08-16 20:17:52 +04:00
|
|
|
goto error;
|
Not as bad as this all may look. Tim and I made a significant change to the way we handle the startup of the oob, the seed, etc. We have made it backwards-compatible so that mpirun2 and singleton operations remain working. We had to adjust the name server and gpr as well, plus the process_info structure.
This also includes a checkpoint update to openmpi.c and ompid.c. I have re-enabled the ompid compile.
This latter raises an important point. The trunk compiles the programs like ompid just fine under Linux. It also does just fine for OSX under the dynamic libraries. However, we are seeing errors when compiling under OSX for the static case - the linker seems to have trouble resolving some variable names, even though linker diagnostics show the variables as being defined. Thus, a warning to Mac users that you may have to locally turn things off if you are trying to do static compiles. We ask, however, that you don't commit those changes that turn things off for everyone else - instead, let's try to figure out why the static compile is having a problem, and let everyone else continue to work.
Thanks
Ralph
This commit was SVN r2534.
2004-09-08 07:59:06 +04:00
|
|
|
}
|
2008-05-20 01:57:54 +04:00
|
|
|
orte_setup = true;
|
These changes were mostly captured in a prior RFC (except for #2 below) and are aimed specifically at improving startup performance and setting up the remaining modifications described in that RFC.
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.
2007-10-05 23:48:23 +04:00
|
|
|
|
2006-11-03 19:04:40 +03:00
|
|
|
/* check for timing request - get stop time and report elapsed time if so */
|
2008-03-27 18:17:53 +03:00
|
|
|
if (timing && 0 == ORTE_PROC_MY_NAME->vpid) {
|
2006-11-03 19:04:40 +03:00
|
|
|
gettimeofday(&ompistop, NULL);
|
2008-06-09 18:53:58 +04:00
|
|
|
opal_output(0, "ompi_mpi_init [%ld]: time from start to completion of orte_init %ld usec",
|
2006-11-03 19:04:40 +03:00
|
|
|
(long)ORTE_PROC_MY_NAME->vpid,
|
|
|
|
(long int)((ompistop.tv_sec - ompistart.tv_sec)*1000000 +
|
|
|
|
(ompistop.tv_usec - ompistart.tv_usec)));
|
|
|
|
gettimeofday(&ompistart, NULL);
|
|
|
|
}
|
2008-10-28 21:29:57 +03:00
|
|
|
|
|
|
|
/* Figure out the final MPI thread levels. If we were not
|
|
|
|
compiled for support for MPI threads, then don't allow
|
|
|
|
MPI_THREAD_MULTIPLE. Set this stuff up here early in the
|
|
|
|
process so that other components can make decisions based on
|
|
|
|
this value. */
|
|
|
|
|
|
|
|
ompi_mpi_thread_requested = requested;
|
2009-05-07 00:11:28 +04:00
|
|
|
if (OPAL_HAVE_THREAD_SUPPORT == 0) {
|
2008-10-28 21:29:57 +03:00
|
|
|
ompi_mpi_thread_provided = *provided = MPI_THREAD_SINGLE;
|
|
|
|
ompi_mpi_main_thread = NULL;
|
2009-05-07 00:11:28 +04:00
|
|
|
} else if (OPAL_ENABLE_MPI_THREADS == 1) {
|
2008-10-28 21:29:57 +03:00
|
|
|
ompi_mpi_thread_provided = *provided = requested;
|
|
|
|
ompi_mpi_main_thread = opal_thread_get_self();
|
|
|
|
} else {
|
|
|
|
if (MPI_THREAD_MULTIPLE == requested) {
|
|
|
|
ompi_mpi_thread_provided = *provided = MPI_THREAD_SERIALIZED;
|
|
|
|
} else {
|
|
|
|
ompi_mpi_thread_provided = *provided = requested;
|
|
|
|
}
|
|
|
|
ompi_mpi_main_thread = opal_thread_get_self();
|
|
|
|
}
|
|
|
|
|
|
|
|
ompi_mpi_thread_multiple = (ompi_mpi_thread_provided ==
|
|
|
|
MPI_THREAD_MULTIPLE);
|
|
|
|
|
2009-07-07 22:32:14 +04:00
|
|
|
|
|
|
|
/* determine the bitflag belonging to the threadlevel_support provided */
|
|
|
|
memset ( &threadlevel_bf, 0, sizeof(uint8_t));
|
|
|
|
OMPI_THREADLEVEL_SET_BITFLAG ( ompi_mpi_thread_provided, threadlevel_bf );
|
|
|
|
|
|
|
|
/* add this bitflag to the modex */
|
|
|
|
if ( OMPI_SUCCESS != (ret = ompi_modex_send_string("MPI_THREAD_LEVEL", &threadlevel_bf, sizeof(uint8_t)))) {
|
|
|
|
error = "ompi_mpi_init: modex send thread level";
|
|
|
|
goto error;
|
|
|
|
}
|
|
|
|
|
2004-08-14 05:56:05 +04:00
|
|
|
/* Once we've joined the RTE, see if any MCA parameters were
|
|
|
|
passed to the MPI level */
|
|
|
|
|
|
|
|
if (OMPI_SUCCESS != (ret = ompi_mpi_register_params())) {
|
2004-09-05 20:05:37 +04:00
|
|
|
error = "mca_mpi_register_params() failed";
|
|
|
|
goto error;
|
2004-08-14 05:56:05 +04:00
|
|
|
}
|
|
|
|
|
2009-04-27 18:15:33 +04:00
|
|
|
/* If desired, send a notify message */
|
|
|
|
if (ompi_notify_init_finalize) {
|
|
|
|
orte_notifier.log(ORTE_NOTIFIER_NOTICE,
|
|
|
|
ORTE_SUCCESS,
|
|
|
|
"MPI_INIT:Starting on host %s, pid %d",
|
|
|
|
orte_process_info.nodename,
|
|
|
|
orte_process_info.pid);
|
|
|
|
}
|
|
|
|
|
2009-05-12 06:18:35 +04:00
|
|
|
/* if it hasn't already been done, setup process affinity.
|
|
|
|
* First check to see if a slot list was
|
|
|
|
* specified. If so, use it. If no slot list was specified,
|
|
|
|
* that's not an error -- just fall through and try the next
|
|
|
|
* paffinity scheme.
|
|
|
|
*/
|
|
|
|
ret = opal_paffinity_base_get(&mask);
|
2009-06-09 18:33:35 +04:00
|
|
|
if (OPAL_SUCCESS == ret) {
|
|
|
|
/* paffinity is supported - check for binding */
|
|
|
|
OPAL_PAFFINITY_PROCESS_IS_BOUND(mask, &proc_bound);
|
|
|
|
if (proc_bound) {
|
|
|
|
/* someone external set it - indicate it is set
|
|
|
|
* so that we know
|
|
|
|
*/
|
2009-05-12 06:18:35 +04:00
|
|
|
paffinity_enabled = true;
|
2009-06-09 18:33:35 +04:00
|
|
|
} else {
|
|
|
|
/* the system is capable of doing processor affinity, but it
|
|
|
|
* has not yet been set - see if a slot_list was given
|
|
|
|
*/
|
|
|
|
if (NULL != opal_paffinity_base_slot_list) {
|
|
|
|
/* It's an error if multiple paffinity schemes were specified */
|
|
|
|
if (opal_paffinity_alone) {
|
|
|
|
ret = OMPI_ERR_BAD_PARAM;
|
|
|
|
error = "Multiple processor affinity schemes specified (can only specify one)";
|
|
|
|
goto error;
|
|
|
|
}
|
|
|
|
ret = opal_paffinity_base_slot_list_set((long)ORTE_PROC_MY_NAME->vpid, opal_paffinity_base_slot_list);
|
|
|
|
if (OPAL_ERR_NOT_FOUND != ret) {
|
|
|
|
error = "opal_paffinity_base_slot_list_set() returned an error";
|
|
|
|
goto error;
|
|
|
|
}
|
|
|
|
paffinity_enabled = true;
|
|
|
|
} else if (opal_paffinity_alone) {
|
|
|
|
/* no slot_list, but they asked for paffinity */
|
|
|
|
int phys_cpu;
|
|
|
|
orte_node_rank_t nrank;
|
|
|
|
if (ORTE_NODE_RANK_INVALID == (nrank = orte_ess.get_node_rank(ORTE_PROC_MY_NAME))) {
|
|
|
|
error = "Could not get node rank - cannot set processor affinity";
|
|
|
|
goto error;
|
|
|
|
}
|
|
|
|
OPAL_PAFFINITY_CPU_ZERO(mask);
|
|
|
|
phys_cpu = opal_paffinity_base_get_physical_processor_id(nrank);
|
|
|
|
if (0 > phys_cpu) {
|
|
|
|
error = "Could not get physical processor id - cannot set processor affinity";
|
|
|
|
goto error;
|
|
|
|
}
|
|
|
|
OPAL_PAFFINITY_CPU_SET(phys_cpu, mask);
|
|
|
|
ret = opal_paffinity_base_set(mask);
|
|
|
|
if (OPAL_SUCCESS != ret) {
|
|
|
|
error = "Setting processor affinity failed";
|
|
|
|
goto error;
|
|
|
|
}
|
|
|
|
paffinity_enabled = true;
|
2009-05-12 06:18:35 +04:00
|
|
|
}
|
2008-07-11 01:12:45 +04:00
|
|
|
}
|
|
|
|
}
|
2009-06-09 18:33:35 +04:00
|
|
|
|
2008-07-11 01:12:45 +04:00
|
|
|
/* If we were able to set processor affinity, try setting up
|
|
|
|
memory affinity */
|
2009-05-12 06:18:35 +04:00
|
|
|
if (!opal_maffinity_setup && paffinity_enabled) {
|
2008-03-30 15:52:11 +04:00
|
|
|
if (OPAL_SUCCESS == opal_maffinity_base_open() &&
|
2008-07-11 01:12:45 +04:00
|
|
|
OPAL_SUCCESS == opal_maffinity_base_select()) {
|
2009-05-12 06:18:35 +04:00
|
|
|
opal_maffinity_setup = true;
|
2007-02-07 17:22:37 +03:00
|
|
|
}
|
|
|
|
}
|
2008-07-03 17:39:34 +04:00
|
|
|
|
2005-08-16 20:17:52 +04:00
|
|
|
/* initialize datatypes. This step should be done early as it will
|
|
|
|
* create the local convertor and local arch used in the proc
|
|
|
|
* init.
|
2005-07-29 04:15:26 +04:00
|
|
|
*/
|
2009-07-13 08:59:13 +04:00
|
|
|
if (OMPI_SUCCESS != (ret = ompi_datatype_init())) {
|
|
|
|
error = "ompi_datatype_init() failed";
|
2005-07-29 04:15:26 +04:00
|
|
|
goto error;
|
|
|
|
}
|
2005-03-27 17:05:23 +04:00
|
|
|
|
2005-07-29 04:15:26 +04:00
|
|
|
/* Initialize OMPI procs */
|
2004-06-07 19:33:53 +04:00
|
|
|
if (OMPI_SUCCESS != (ret = ompi_proc_init())) {
|
2004-09-05 20:05:37 +04:00
|
|
|
error = "mca_proc_init() failed";
|
|
|
|
goto error;
|
2004-03-03 19:44:41 +03:00
|
|
|
}
|
|
|
|
|
Two major things in this commit:
* New "op" MPI layer framework
* Addition of the MPI_REDUCE_LOCAL proposed function (for MPI-2.2)
= Op framework =
Add new "op" framework in the ompi layer. This framework replaces the
hard-coded MPI_Op back-end functions for (MPI_Op, MPI_Datatype) tuples
for pre-defined MPI_Ops, allowing components and modules to provide
the back-end functions. The intent is that components can be written
to take advantage of hardware acceleration (GPU, FPGA, specialized CPU
instructions, etc.). Similar to other frameworks, components are
intended to be able to discover at run-time if they can be used, and
if so, elect themselves to be selected (or disqualify themselves from
selection if they cannot run). If specialized hardware is not
available, there is a default set of functions that will automatically
be used.
This framework is ''not'' used for user-defined MPI_Ops.
The new op framework is similar to the existing coll framework, in
that the final set of function pointers that are used on any given
intrinsic MPI_Op can be a mixed bag of function pointers, potentially
coming from multiple different op modules. This allows for hardware
that only supports some of the operations, not all of them (e.g., a
GPU that only supports single-precision operations).
All the hard-coded back-end MPI_Op functions for (MPI_Op,
MPI_Datatype) tuples still exist, but unlike coll, they're in the
framework base (vs. being in a separate "basic" component) and are
automatically used if no component is found at runtime that provides a
module with the necessary function pointers.
There is an "example" op component that will hopefully be useful to
those writing meaningful op components. It is currently
.ompi_ignore'd so that it doesn't impinge on other developers (it's
somewhat chatty in terms of opal_output() so that you can tell when
its functions have been invoked). See the README file in the example
op component directory. Developers of new op components are
encouraged to look at the following wiki pages:
https://svn.open-mpi.org/trac/ompi/wiki/devel/Autogen
https://svn.open-mpi.org/trac/ompi/wiki/devel/CreateComponent
https://svn.open-mpi.org/trac/ompi/wiki/devel/CreateFramework
= MPI_REDUCE_LOCAL =
Part of the MPI-2.2 proposal listed here:
https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/24
is to add a new function named MPI_REDUCE_LOCAL. It is very easy to
implement, so I added it (also because it makes testing the op
framework pretty easy -- you can do it in serial rather than via
parallel reductions). There's even a man page!
This commit was SVN r20280.
2009-01-15 02:44:31 +03:00
|
|
|
/* Initialize the op framework. This has to be done *after*
|
|
|
|
ddt_init, but befor mca_coll_base_open, since some collective
|
|
|
|
modules (e.g., the hierarchical coll component) may need ops in
|
|
|
|
their query function. */
|
|
|
|
if (OMPI_SUCCESS != (ret = ompi_op_base_open())) {
|
|
|
|
error = "ompi_op_base_open() failed";
|
|
|
|
goto error;
|
|
|
|
}
|
|
|
|
if (OMPI_SUCCESS !=
|
2009-05-07 00:11:28 +04:00
|
|
|
(ret = ompi_op_base_find_available(OPAL_ENABLE_PROGRESS_THREADS,
|
|
|
|
OPAL_ENABLE_MPI_THREADS))) {
|
Two major things in this commit:
* New "op" MPI layer framework
* Addition of the MPI_REDUCE_LOCAL proposed function (for MPI-2.2)
= Op framework =
Add new "op" framework in the ompi layer. This framework replaces the
hard-coded MPI_Op back-end functions for (MPI_Op, MPI_Datatype) tuples
for pre-defined MPI_Ops, allowing components and modules to provide
the back-end functions. The intent is that components can be written
to take advantage of hardware acceleration (GPU, FPGA, specialized CPU
instructions, etc.). Similar to other frameworks, components are
intended to be able to discover at run-time if they can be used, and
if so, elect themselves to be selected (or disqualify themselves from
selection if they cannot run). If specialized hardware is not
available, there is a default set of functions that will automatically
be used.
This framework is ''not'' used for user-defined MPI_Ops.
The new op framework is similar to the existing coll framework, in
that the final set of function pointers that are used on any given
intrinsic MPI_Op can be a mixed bag of function pointers, potentially
coming from multiple different op modules. This allows for hardware
that only supports some of the operations, not all of them (e.g., a
GPU that only supports single-precision operations).
All the hard-coded back-end MPI_Op functions for (MPI_Op,
MPI_Datatype) tuples still exist, but unlike coll, they're in the
framework base (vs. being in a separate "basic" component) and are
automatically used if no component is found at runtime that provides a
module with the necessary function pointers.
There is an "example" op component that will hopefully be useful to
those writing meaningful op components. It is currently
.ompi_ignore'd so that it doesn't impinge on other developers (it's
somewhat chatty in terms of opal_output() so that you can tell when
its functions have been invoked). See the README file in the example
op component directory. Developers of new op components are
encouraged to look at the following wiki pages:
https://svn.open-mpi.org/trac/ompi/wiki/devel/Autogen
https://svn.open-mpi.org/trac/ompi/wiki/devel/CreateComponent
https://svn.open-mpi.org/trac/ompi/wiki/devel/CreateFramework
= MPI_REDUCE_LOCAL =
Part of the MPI-2.2 proposal listed here:
https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/24
is to add a new function named MPI_REDUCE_LOCAL. It is very easy to
implement, so I added it (also because it makes testing the op
framework pretty easy -- you can do it in serial rather than via
parallel reductions). There's even a man page!
This commit was SVN r20280.
2009-01-15 02:44:31 +03:00
|
|
|
error = "ompi_op_base_find_available() failed";
|
|
|
|
goto error;
|
|
|
|
}
|
2005-10-25 22:33:48 +04:00
|
|
|
if (OMPI_SUCCESS != (ret = ompi_op_init())) {
|
|
|
|
error = "ompi_op_init() failed";
|
|
|
|
goto error;
|
|
|
|
}
|
|
|
|
|
2005-03-27 17:05:23 +04:00
|
|
|
/* Open up MPI-related MCA components */
|
2004-08-14 05:56:05 +04:00
|
|
|
|
2004-06-17 20:23:34 +04:00
|
|
|
if (OMPI_SUCCESS != (ret = mca_allocator_base_open())) {
|
2004-09-05 20:05:37 +04:00
|
|
|
error = "mca_allocator_base_open() failed";
|
|
|
|
goto error;
|
2004-06-17 20:23:34 +04:00
|
|
|
}
|
2005-09-13 02:28:23 +04:00
|
|
|
if (OMPI_SUCCESS != (ret = mca_rcache_base_open())) {
|
|
|
|
error = "mca_rcache_base_open() failed";
|
|
|
|
goto error;
|
|
|
|
}
|
2004-06-17 20:23:34 +04:00
|
|
|
if (OMPI_SUCCESS != (ret = mca_mpool_base_open())) {
|
2004-09-05 20:05:37 +04:00
|
|
|
error = "mca_mpool_base_open() failed";
|
|
|
|
goto error;
|
2004-06-17 20:23:34 +04:00
|
|
|
}
|
2004-06-07 19:33:53 +04:00
|
|
|
if (OMPI_SUCCESS != (ret = mca_pml_base_open())) {
|
2004-09-05 20:05:37 +04:00
|
|
|
error = "mca_pml_base_open() failed";
|
|
|
|
goto error;
|
2004-02-13 16:56:55 +03:00
|
|
|
}
|
2004-06-07 19:33:53 +04:00
|
|
|
if (OMPI_SUCCESS != (ret = mca_coll_base_open())) {
|
2004-09-05 20:05:37 +04:00
|
|
|
error = "mca_coll_base_open() failed";
|
|
|
|
goto error;
|
2004-02-13 16:56:55 +03:00
|
|
|
}
|
2004-01-30 06:59:39 +03:00
|
|
|
|
2006-01-28 18:38:37 +03:00
|
|
|
if (OMPI_SUCCESS != (ret = ompi_osc_base_open())) {
|
|
|
|
error = "ompi_osc_base_open() failed";
|
|
|
|
goto error;
|
|
|
|
}
|
|
|
|
|
2007-03-17 02:11:45 +03:00
|
|
|
#if OPAL_ENABLE_FT == 1
|
|
|
|
if (OMPI_SUCCESS != (ret = ompi_crcp_base_open())) {
|
|
|
|
error = "ompi_crcp_base_open() failed";
|
|
|
|
goto error;
|
|
|
|
}
|
|
|
|
#endif
|
|
|
|
|
2005-03-27 17:05:23 +04:00
|
|
|
/* In order to reduce the common case for MPI apps (where they
|
|
|
|
don't use MPI-2 IO or MPI-1 topology functions), the io and
|
|
|
|
topo frameworks are initialized lazily, at the first use of
|
|
|
|
relevant functions (e.g., MPI_FILE_*, MPI_CART_*, MPI_GRAPH_*),
|
|
|
|
so they are not opened here. */
|
|
|
|
|
|
|
|
/* Select which MPI components to use */
|
2004-01-30 06:59:39 +03:00
|
|
|
|
2004-06-07 19:33:53 +04:00
|
|
|
if (OMPI_SUCCESS !=
|
2009-05-07 00:11:28 +04:00
|
|
|
(ret = mca_mpool_base_init(OPAL_ENABLE_PROGRESS_THREADS,
|
|
|
|
OPAL_ENABLE_MPI_THREADS))) {
|
2005-03-27 17:05:23 +04:00
|
|
|
error = "mca_mpool_base_init() failed";
|
2004-09-05 20:05:37 +04:00
|
|
|
goto error;
|
|
|
|
}
|
|
|
|
|
2005-03-27 17:05:23 +04:00
|
|
|
if (OMPI_SUCCESS !=
|
2009-05-07 00:11:28 +04:00
|
|
|
(ret = mca_pml_base_select(OPAL_ENABLE_PROGRESS_THREADS,
|
|
|
|
OPAL_ENABLE_MPI_THREADS))) {
|
2005-03-27 17:05:23 +04:00
|
|
|
error = "mca_pml_base_select() failed";
|
|
|
|
goto error;
|
|
|
|
}
|
|
|
|
|
2007-07-17 01:52:25 +04:00
|
|
|
/* select buffered send allocator component to be used */
|
2009-05-07 00:11:28 +04:00
|
|
|
ret=mca_pml_base_bsend_init(OPAL_ENABLE_MPI_THREADS);
|
2007-07-17 01:52:25 +04:00
|
|
|
if( OMPI_SUCCESS != ret ) {
|
|
|
|
error = "mca_pml_base_bsend_init() failed";
|
|
|
|
goto error;
|
|
|
|
}
|
|
|
|
|
2005-03-27 17:05:23 +04:00
|
|
|
if (OMPI_SUCCESS !=
|
2009-05-07 00:11:28 +04:00
|
|
|
(ret = mca_coll_base_find_available(OPAL_ENABLE_PROGRESS_THREADS,
|
|
|
|
OPAL_ENABLE_MPI_THREADS))) {
|
2005-03-27 17:05:23 +04:00
|
|
|
error = "mca_coll_base_find_available() failed";
|
|
|
|
goto error;
|
|
|
|
}
|
|
|
|
|
2006-01-28 18:38:37 +03:00
|
|
|
if (OMPI_SUCCESS !=
|
2009-05-07 00:11:28 +04:00
|
|
|
(ret = ompi_osc_base_find_available(OPAL_ENABLE_PROGRESS_THREADS,
|
|
|
|
OPAL_ENABLE_MPI_THREADS))) {
|
2006-01-28 18:38:37 +03:00
|
|
|
error = "ompi_osc_base_find_available() failed";
|
|
|
|
goto error;
|
|
|
|
}
|
|
|
|
|
2007-03-17 02:11:45 +03:00
|
|
|
#if OPAL_ENABLE_FT == 1
|
|
|
|
if (OMPI_SUCCESS != (ret = ompi_crcp_base_select() ) ) {
|
|
|
|
error = "ompi_crcp_base_select() failed";
|
|
|
|
goto error;
|
|
|
|
}
|
|
|
|
#endif
|
|
|
|
|
2005-03-27 17:05:23 +04:00
|
|
|
/* io and topo components are not selected here -- see comment
|
|
|
|
above about the io and topo frameworks being loaded lazily */
|
|
|
|
|
|
|
|
/* Initialize each MPI handle subsystem */
|
2004-10-08 21:12:36 +04:00
|
|
|
/* initialize requests */
|
|
|
|
if (OMPI_SUCCESS != (ret = ompi_request_init())) {
|
|
|
|
error = "ompi_request_init() failed";
|
|
|
|
goto error;
|
|
|
|
}
|
|
|
|
|
2004-09-05 20:05:37 +04:00
|
|
|
/* initialize info */
|
|
|
|
if (OMPI_SUCCESS != (ret = ompi_info_init())) {
|
|
|
|
error = "ompi_info_init() failed";
|
|
|
|
goto error;
|
|
|
|
}
|
2004-10-08 21:12:36 +04:00
|
|
|
|
2004-09-05 20:05:37 +04:00
|
|
|
/* initialize error handlers */
|
|
|
|
if (OMPI_SUCCESS != (ret = ompi_errhandler_init())) {
|
|
|
|
error = "ompi_errhandler_init() failed";
|
|
|
|
goto error;
|
2004-02-13 16:56:55 +03:00
|
|
|
}
|
2004-01-30 06:59:39 +03:00
|
|
|
|
2004-09-05 20:05:37 +04:00
|
|
|
/* initialize error codes */
|
|
|
|
if (OMPI_SUCCESS != (ret = ompi_mpi_errcode_init())) {
|
|
|
|
error = "ompi_mpi_errcode_init() failed";
|
|
|
|
goto error;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* initialize internal error codes */
|
|
|
|
if (OMPI_SUCCESS != (ret = ompi_errcode_intern_init())) {
|
|
|
|
error = "ompi_errcode_intern_init() failed";
|
|
|
|
goto error;
|
|
|
|
}
|
2004-05-08 03:23:03 +04:00
|
|
|
|
2004-09-05 20:05:37 +04:00
|
|
|
/* initialize groups */
|
|
|
|
if (OMPI_SUCCESS != (ret = ompi_group_init())) {
|
|
|
|
error = "ompi_group_init() failed";
|
|
|
|
goto error;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* initialize communicators */
|
|
|
|
if (OMPI_SUCCESS != (ret = ompi_comm_init())) {
|
|
|
|
error = "ompi_comm_init() failed";
|
|
|
|
goto error;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* initialize file handles */
|
|
|
|
if (OMPI_SUCCESS != (ret = ompi_file_init())) {
|
|
|
|
error = "ompi_file_init() failed";
|
|
|
|
goto error;
|
|
|
|
}
|
|
|
|
|
2006-01-28 18:38:37 +03:00
|
|
|
/* initialize windows */
|
|
|
|
if (OMPI_SUCCESS != (ret = ompi_win_init())) {
|
|
|
|
error = "ompi_win_init() failed";
|
|
|
|
goto error;
|
|
|
|
}
|
|
|
|
|
2004-09-16 04:00:09 +04:00
|
|
|
/* initialize attribute meta-data structure for comm/win/dtype */
|
|
|
|
if (OMPI_SUCCESS != (ret = ompi_attr_init())) {
|
|
|
|
error = "ompi_attr_init() failed";
|
|
|
|
goto error;
|
|
|
|
}
|
2004-11-20 22:12:43 +03:00
|
|
|
|
2006-09-29 17:19:44 +04:00
|
|
|
/* check for timing request - get stop time and report elapsed time if so */
|
2008-03-27 18:17:53 +03:00
|
|
|
if (timing && 0 == ORTE_PROC_MY_NAME->vpid) {
|
2006-11-03 19:04:40 +03:00
|
|
|
gettimeofday(&ompistop, NULL);
|
2008-06-09 18:53:58 +04:00
|
|
|
opal_output(0, "ompi_mpi_init[%ld]: time from completion of orte_init to modex %ld usec",
|
2006-11-03 19:04:40 +03:00
|
|
|
(long)ORTE_PROC_MY_NAME->vpid,
|
|
|
|
(long int)((ompistop.tv_sec - ompistart.tv_sec)*1000000 +
|
|
|
|
(ompistop.tv_usec - ompistart.tv_usec)));
|
|
|
|
gettimeofday(&ompistart, NULL);
|
2006-09-29 17:19:44 +04:00
|
|
|
}
|
|
|
|
|
2008-02-28 04:57:57 +03:00
|
|
|
/* exchange connection info - this function also acts as a barrier
|
These changes were mostly captured in a prior RFC (except for #2 below) and are aimed specifically at improving startup performance and setting up the remaining modifications described in that RFC.
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.
2007-10-05 23:48:23 +04:00
|
|
|
* as it will not return until the exchange is complete
|
|
|
|
*/
|
2008-02-28 04:57:57 +03:00
|
|
|
if (OMPI_SUCCESS != (ret = orte_grpcomm.modex(NULL))) {
|
|
|
|
error = "orte_grpcomm_modex failed";
|
2005-08-16 20:17:52 +04:00
|
|
|
goto error;
|
2004-11-20 22:12:43 +03:00
|
|
|
}
|
2008-08-01 02:11:46 +04:00
|
|
|
|
2008-03-27 18:17:53 +03:00
|
|
|
if (timing && 0 == ORTE_PROC_MY_NAME->vpid) {
|
2006-11-30 18:06:40 +03:00
|
|
|
gettimeofday(&ompistop, NULL);
|
2008-06-09 18:53:58 +04:00
|
|
|
opal_output(0, "ompi_mpi_init[%ld]: time to execute modex %ld usec",
|
2006-11-30 18:06:40 +03:00
|
|
|
(long)ORTE_PROC_MY_NAME->vpid,
|
|
|
|
(long int)((ompistop.tv_sec - ompistart.tv_sec)*1000000 +
|
|
|
|
(ompistop.tv_usec - ompistart.tv_usec)));
|
2006-11-03 19:04:40 +03:00
|
|
|
gettimeofday(&ompistart, NULL);
|
Bring the timing instrumentation to the trunk.
If you want to look at our launch and MPI process startup times, you can do so with two MCA params:
OMPI_MCA_orte_timing: set it to anything non-zero and you will get the launch time for different steps in the job launch procedure. The degree of detail depends on the launch environment. rsh will provide you with the average, min, and max launch time for the daemons. SLURM block launches the daemon, so you only get the time to launch the daemons and the total time to launch the job. Ditto for bproc. TM looks more like rsh. Only those four environments are currently supported - anyone interested in extending this capability to other environs is welcome to do so. In all cases, you also get the time to setup the job for launch.
OMPI_MCA_ompi_timing: set it to anything non-zero and you will get the time for mpi_init to reach the compound registry command, the time to execute that command, the time to go from our stage1 barrier to the stage2 barrier, and the time to go from the stage2 barrier to the end of mpi_init. This will be output for each process, so you'll have to compile any statistics on your own. Note: if someone develops a nice parser to do so, it would be really appreciated if you could/would share!
This commit was SVN r12302.
2006-10-25 19:27:47 +04:00
|
|
|
}
|
These changes were mostly captured in a prior RFC (except for #2 below) and are aimed specifically at improving startup performance and setting up the remaining modifications described in that RFC.
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.
2007-10-05 23:48:23 +04:00
|
|
|
|
2008-06-19 02:17:53 +04:00
|
|
|
/* identify the architectures of remote procs and setup
|
|
|
|
* their datatype convertors, if required
|
|
|
|
*/
|
|
|
|
if (OMPI_SUCCESS != (ret = ompi_proc_set_arch())) {
|
|
|
|
error = "ompi_proc_set_arch failed";
|
|
|
|
goto error;
|
|
|
|
}
|
2005-03-27 17:05:23 +04:00
|
|
|
|
2008-10-28 21:29:57 +03:00
|
|
|
/* If thread support was enabled, then setup OPAL to allow for
|
|
|
|
them. */
|
2009-05-07 00:11:28 +04:00
|
|
|
if ((OPAL_ENABLE_PROGRESS_THREADS == 1) ||
|
2006-08-15 19:55:53 +04:00
|
|
|
(*provided != MPI_THREAD_SINGLE)) {
|
2005-07-04 02:45:48 +04:00
|
|
|
opal_set_using_threads(true);
|
2005-03-27 17:05:23 +04:00
|
|
|
}
|
2004-02-05 04:52:56 +03:00
|
|
|
|
2007-08-04 04:37:52 +04:00
|
|
|
/* start PML/BTL's */
|
2007-04-07 09:06:47 +04:00
|
|
|
ret = MCA_PML_CALL(enable(true));
|
|
|
|
if( OMPI_SUCCESS != ret ) {
|
|
|
|
error = "PML control failed";
|
|
|
|
goto error;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* add all ompi_proc_t's to PML */
|
|
|
|
if (NULL == (procs = ompi_proc_world(&nprocs))) {
|
|
|
|
error = "ompi_proc_world() failed";
|
|
|
|
goto error;
|
|
|
|
}
|
|
|
|
ret = MCA_PML_CALL(add_procs(procs, nprocs));
|
|
|
|
free(procs);
|
|
|
|
if( OMPI_SUCCESS != ret ) {
|
|
|
|
error = "PML add procs failed";
|
|
|
|
goto error;
|
|
|
|
}
|
|
|
|
|
2009-02-24 20:17:33 +03:00
|
|
|
MCA_PML_CALL(add_comm(&ompi_mpi_comm_world.comm));
|
|
|
|
MCA_PML_CALL(add_comm(&ompi_mpi_comm_self.comm));
|
2007-04-07 09:06:47 +04:00
|
|
|
|
2005-11-12 06:47:17 +03:00
|
|
|
|
2005-07-09 01:01:37 +04:00
|
|
|
/*
|
|
|
|
* Dump all MCA parameters if requested
|
|
|
|
*/
|
|
|
|
if (ompi_mpi_show_mca_params) {
|
2009-02-24 20:17:33 +03:00
|
|
|
ompi_show_all_mca_params(ompi_mpi_comm_world.comm.c_my_rank,
|
2005-07-09 01:01:37 +04:00
|
|
|
nprocs,
|
2009-03-06 00:56:03 +03:00
|
|
|
orte_process_info.nodename);
|
2005-07-09 01:01:37 +04:00
|
|
|
}
|
|
|
|
|
2008-06-18 19:28:46 +04:00
|
|
|
/* Do we need to wait for a debugger? */
|
2008-12-11 00:13:10 +03:00
|
|
|
#ifndef __WINDOWS__
|
2008-06-18 19:28:46 +04:00
|
|
|
ompi_wait_for_debugger();
|
2008-12-11 00:13:10 +03:00
|
|
|
#endif
|
2008-06-18 19:28:46 +04:00
|
|
|
|
|
|
|
/* check for timing request - get stop time and report elapsed
|
|
|
|
time if so, then start the clock again */
|
|
|
|
if (timing && 0 == ORTE_PROC_MY_NAME->vpid) {
|
|
|
|
gettimeofday(&ompistop, NULL);
|
2009-01-07 00:30:12 +03:00
|
|
|
opal_output(0, "ompi_mpi_init[%ld]: time from modex to first barrier %ld usec",
|
2008-06-18 19:28:46 +04:00
|
|
|
(long)ORTE_PROC_MY_NAME->vpid,
|
|
|
|
(long int)((ompistop.tv_sec - ompistart.tv_sec)*1000000 +
|
|
|
|
(ompistop.tv_usec - ompistart.tv_usec)));
|
|
|
|
gettimeofday(&ompistart, NULL);
|
|
|
|
}
|
|
|
|
|
|
|
|
/* wait for everyone to reach this point */
|
|
|
|
if (OMPI_SUCCESS != (ret = orte_grpcomm.barrier())) {
|
|
|
|
error = "orte_grpcomm_barrier failed";
|
|
|
|
goto error;
|
|
|
|
}
|
|
|
|
|
2007-02-09 23:17:37 +03:00
|
|
|
/* check for timing request - get stop time and report elapsed
|
|
|
|
time if so, then start the clock again */
|
2008-03-27 18:17:53 +03:00
|
|
|
if (timing && 0 == ORTE_PROC_MY_NAME->vpid) {
|
2007-02-09 23:17:37 +03:00
|
|
|
gettimeofday(&ompistop, NULL);
|
2008-06-18 19:28:46 +04:00
|
|
|
opal_output(0, "ompi_mpi_init[%ld]: time to execute barrier %ld usec",
|
2007-02-09 23:17:37 +03:00
|
|
|
(long)ORTE_PROC_MY_NAME->vpid,
|
|
|
|
(long int)((ompistop.tv_sec - ompistart.tv_sec)*1000000 +
|
|
|
|
(ompistop.tv_usec - ompistart.tv_usec)));
|
|
|
|
gettimeofday(&ompistart, NULL);
|
|
|
|
}
|
|
|
|
|
2009-05-07 00:11:28 +04:00
|
|
|
#if OPAL_ENABLE_PROGRESS_THREADS == 0
|
2007-02-01 21:47:43 +03:00
|
|
|
/* Start setting up the event engine for MPI operations. Don't
|
|
|
|
block in the event library, so that communications don't take
|
|
|
|
forever between procs in the dynamic code. This will increase
|
|
|
|
CPU utilization for the remainder of MPI_INIT when we are
|
|
|
|
blocking on ORTE-level events, but may greatly reduce non-TCP
|
|
|
|
latency. */
|
|
|
|
opal_progress_set_event_flag(OPAL_EVLOOP_NONBLOCK);
|
|
|
|
#endif
|
2007-05-01 08:49:36 +04:00
|
|
|
|
|
|
|
/* wire up the mpi interface, if requested. Do this after the
|
|
|
|
non-block switch for non-TCP performance. Do before the
|
|
|
|
polling change as anyone with a complex wire-up is going to be
|
|
|
|
using the oob. */
|
|
|
|
if (OMPI_SUCCESS != (ret = ompi_init_preconnect_mpi())) {
|
|
|
|
error = "ompi_mpi_do_preconnect_all() failed";
|
|
|
|
goto error;
|
|
|
|
}
|
2007-02-01 21:47:43 +03:00
|
|
|
|
2008-02-28 04:57:57 +03:00
|
|
|
/* Setup the publish/subscribe (PUBSUB) framework */
|
|
|
|
if (OMPI_SUCCESS != (ret = ompi_pubsub_base_open())) {
|
|
|
|
error = "ompi_pubsub_base_open() failed";
|
|
|
|
goto error;
|
|
|
|
}
|
|
|
|
if (OMPI_SUCCESS != (ret = ompi_pubsub_base_select())) {
|
|
|
|
error = "ompi_pubsub_base_select() failed";
|
|
|
|
goto error;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Setup the dynamic process management (DPM) framework */
|
|
|
|
if (OMPI_SUCCESS != (ret = ompi_dpm_base_open())) {
|
|
|
|
error = "ompi_dpm_base_open() failed";
|
|
|
|
goto error;
|
|
|
|
}
|
|
|
|
if (OMPI_SUCCESS != (ret = ompi_dpm_base_select())) {
|
|
|
|
error = "ompi_dpm_base_select() failed";
|
|
|
|
goto error;
|
|
|
|
}
|
2008-03-31 23:37:37 +04:00
|
|
|
|
2009-07-07 22:32:14 +04:00
|
|
|
|
|
|
|
/* Determine the overall threadlevel support of all processes
|
|
|
|
in MPI_COMM_WORLD. This has to be done before calling
|
|
|
|
coll_base_comm_select, since some of the collective components
|
|
|
|
e.g. hierarch, might create subcommunicators. The threadlevel
|
|
|
|
requested by all processes is required in order to know
|
|
|
|
which cid allocation algorithm can be used. */
|
|
|
|
if ( OMPI_SUCCESS !=
|
|
|
|
( ret = ompi_comm_cid_init ())) {
|
|
|
|
error = "ompi_mpi_init: ompi_comm_cid_init failed";
|
|
|
|
goto error;
|
|
|
|
}
|
|
|
|
|
2008-03-31 23:37:37 +04:00
|
|
|
/* Init coll for the comms. This has to be after dpm_base_select,
|
|
|
|
(since dpm.mark_dyncomm is not set in the communicator creation
|
|
|
|
function else), but before dpm.dyncom_init, since this function
|
|
|
|
might require collective for the CID allocation. */
|
|
|
|
if (OMPI_SUCCESS !=
|
|
|
|
(ret = mca_coll_base_comm_select(MPI_COMM_WORLD))) {
|
|
|
|
error = "mca_coll_base_comm_select(MPI_COMM_WORLD) failed";
|
|
|
|
goto error;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (OMPI_SUCCESS !=
|
|
|
|
(ret = mca_coll_base_comm_select(MPI_COMM_SELF))) {
|
|
|
|
error = "mca_coll_base_comm_select(MPI_COMM_SELF) failed";
|
|
|
|
goto error;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
2008-02-28 04:57:57 +03:00
|
|
|
|
2007-02-01 21:47:43 +03:00
|
|
|
/* Check whether we have been spawned or not. We introduce that
|
|
|
|
at the very end, since we need collectives, datatypes, ptls
|
|
|
|
etc. up and running here.... */
|
2008-02-28 04:57:57 +03:00
|
|
|
if (OMPI_SUCCESS != (ret = ompi_dpm.dyn_init())) {
|
2004-09-29 16:41:55 +04:00
|
|
|
error = "ompi_comm_dyn_init() failed";
|
|
|
|
goto error;
|
|
|
|
}
|
|
|
|
|
2007-03-17 02:11:45 +03:00
|
|
|
/*
|
|
|
|
* Startup the Checkpoint/Restart Mech.
|
|
|
|
* Note: Always do this so tools don't hang when
|
|
|
|
* in a non-checkpointable build
|
|
|
|
*/
|
|
|
|
if (OMPI_SUCCESS != (ret = ompi_cr_init())) {
|
|
|
|
error = "ompi_cr_init";
|
|
|
|
goto error;
|
|
|
|
}
|
|
|
|
|
2006-11-22 05:06:52 +03:00
|
|
|
/* Undo ORTE calling opal_progress_event_users_increment() during
|
2007-02-01 21:47:43 +03:00
|
|
|
MPI lifetime, to get better latency when not using TCP. Do
|
|
|
|
this *after* dyn_init, as dyn init uses lots of ORTE
|
|
|
|
communication and we don't want to hinder the performance of
|
|
|
|
that code. */
|
2006-11-22 05:06:52 +03:00
|
|
|
opal_progress_event_users_decrement();
|
|
|
|
|
2008-07-23 07:43:31 +04:00
|
|
|
/* see if yield_when_idle was specified - if so, use it */
|
2006-11-22 05:06:52 +03:00
|
|
|
param = mca_base_param_find("mpi", NULL, "yield_when_idle");
|
|
|
|
mca_base_param_lookup_int(param, &value);
|
|
|
|
if (value < 0) {
|
2008-07-23 07:43:31 +04:00
|
|
|
/* if no info is provided, just default to conservative */
|
2007-02-07 17:22:37 +03:00
|
|
|
opal_progress_set_yield_when_idle(true);
|
2006-11-22 05:06:52 +03:00
|
|
|
} else {
|
2008-07-23 07:43:31 +04:00
|
|
|
/* info was provided, so set idle accordingly */
|
2006-11-22 05:06:52 +03:00
|
|
|
opal_progress_set_yield_when_idle(value == 0 ? false : true);
|
2006-08-04 18:41:31 +04:00
|
|
|
}
|
2008-07-23 07:43:31 +04:00
|
|
|
|
2006-11-22 05:06:52 +03:00
|
|
|
param = mca_base_param_find("mpi", NULL, "event_tick_rate");
|
|
|
|
mca_base_param_lookup_int(param, &value);
|
|
|
|
/* negative value means use default - just don't do anything */
|
|
|
|
if (value >= 0) {
|
|
|
|
opal_progress_set_event_poll_rate(value);
|
|
|
|
}
|
2007-05-01 08:49:36 +04:00
|
|
|
|
2007-02-01 21:47:43 +03:00
|
|
|
/* At this point, we are fully configured and in MPI mode. Any
|
|
|
|
communication calls here will work exactly like they would in
|
|
|
|
the user's code. Setup the connections between procs and warm
|
2007-02-09 23:17:37 +03:00
|
|
|
them up with simple sends, if requested */
|
2005-03-30 05:40:26 +04:00
|
|
|
|
2007-02-01 21:47:43 +03:00
|
|
|
error:
|
|
|
|
if (ret != OMPI_SUCCESS) {
|
|
|
|
const char *err_msg = opal_strerror(ret);
|
2008-05-20 01:57:54 +04:00
|
|
|
/* If ORTE was not setup yet, don't use orte_show_help */
|
|
|
|
if (orte_setup) {
|
|
|
|
orte_show_help("help-mpi-runtime",
|
|
|
|
"mpi_init:startup:internal-failure", true,
|
|
|
|
"MPI_INIT", "MPI_INIT", error, err_msg, ret);
|
|
|
|
} else {
|
|
|
|
opal_show_help("help-mpi-runtime",
|
|
|
|
"mpi_init:startup:internal-failure", true,
|
|
|
|
"MPI_INIT", "MPI_INIT", error, err_msg, ret);
|
|
|
|
}
|
2007-02-01 21:47:43 +03:00
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2007-12-07 16:09:07 +03:00
|
|
|
/* Initialize the registered datarep list to be empty */
|
|
|
|
OBJ_CONSTRUCT(&ompi_registered_datareps, opal_list_t);
|
|
|
|
|
Deal with the ticket #1239 and #712. This will upgrade the Open MPI support
for the F90 type create functions to the requirements of MPI 2.1 standard.
Advice to implementors. An application may often repeat a call to
MPI_TYPE_CREATE_F90_xxxx with the same combination of (xxxx,p,r).
The application is not allowed to free the returned predefined, unnamed
datatype handles. To prevent the creation of a potentially huge amount of
handles, the MPI implementation should return the same datatype handle for
the same (REAL/COMPLEX/INTEGER,p,r) combination. Checking for the
combination (p,r) in the preceding call to MPI_TYPE_CREATE_F90_xxxx and
using a hash-table to find formerly generated handles should limit the
overhead of finding a previously generated datatype with same combination
of (xxxx,p,r). (End of advice to implementors.)
This commit fixes trac:1239, and #712.
This commit was SVN r19458.
The following Trac tickets were found above:
Ticket 1239 --> https://svn.open-mpi.org/trac/ompi/ticket/1239
2008-08-31 22:36:32 +04:00
|
|
|
/* Initialize the arrays used to store the F90 types returned by the
|
|
|
|
* MPI_Type_create_f90_XXX functions.
|
|
|
|
*/
|
|
|
|
OBJ_CONSTRUCT( &ompi_mpi_f90_integer_hashtable, opal_hash_table_t);
|
|
|
|
opal_hash_table_init(&ompi_mpi_f90_integer_hashtable, 16 /* why not? */);
|
|
|
|
|
|
|
|
OBJ_CONSTRUCT( &ompi_mpi_f90_real_hashtable, opal_hash_table_t);
|
|
|
|
opal_hash_table_init(&ompi_mpi_f90_real_hashtable, FLT_MAX_10_EXP);
|
|
|
|
|
|
|
|
OBJ_CONSTRUCT( &ompi_mpi_f90_complex_hashtable, opal_hash_table_t);
|
|
|
|
opal_hash_table_init(&ompi_mpi_f90_complex_hashtable, FLT_MAX_10_EXP);
|
|
|
|
|
2005-03-27 17:05:23 +04:00
|
|
|
/* All done. Wasn't that simple? */
|
2004-02-05 04:52:56 +03:00
|
|
|
|
2004-06-07 19:33:53 +04:00
|
|
|
ompi_mpi_initialized = true;
|
2004-11-20 22:12:43 +03:00
|
|
|
|
Bring the timing instrumentation to the trunk.
If you want to look at our launch and MPI process startup times, you can do so with two MCA params:
OMPI_MCA_orte_timing: set it to anything non-zero and you will get the launch time for different steps in the job launch procedure. The degree of detail depends on the launch environment. rsh will provide you with the average, min, and max launch time for the daemons. SLURM block launches the daemon, so you only get the time to launch the daemons and the total time to launch the job. Ditto for bproc. TM looks more like rsh. Only those four environments are currently supported - anyone interested in extending this capability to other environs is welcome to do so. In all cases, you also get the time to setup the job for launch.
OMPI_MCA_ompi_timing: set it to anything non-zero and you will get the time for mpi_init to reach the compound registry command, the time to execute that command, the time to go from our stage1 barrier to the stage2 barrier, and the time to go from the stage2 barrier to the end of mpi_init. This will be output for each process, so you'll have to compile any statistics on your own. Note: if someone develops a nice parser to do so, it would be really appreciated if you could/would share!
This commit was SVN r12302.
2006-10-25 19:27:47 +04:00
|
|
|
/* check for timing request - get stop time and report elapsed time if so */
|
2008-03-27 18:17:53 +03:00
|
|
|
if (timing && 0 == ORTE_PROC_MY_NAME->vpid) {
|
2006-11-03 19:04:40 +03:00
|
|
|
gettimeofday(&ompistop, NULL);
|
2009-01-07 00:30:12 +03:00
|
|
|
opal_output(0, "ompi_mpi_init[%ld]: time from barrier to complete mpi_init %ld usec",
|
2006-11-03 19:04:40 +03:00
|
|
|
(long)ORTE_PROC_MY_NAME->vpid,
|
|
|
|
(long int)((ompistop.tv_sec - ompistart.tv_sec)*1000000 +
|
|
|
|
(ompistop.tv_usec - ompistart.tv_usec)));
|
Bring the timing instrumentation to the trunk.
If you want to look at our launch and MPI process startup times, you can do so with two MCA params:
OMPI_MCA_orte_timing: set it to anything non-zero and you will get the launch time for different steps in the job launch procedure. The degree of detail depends on the launch environment. rsh will provide you with the average, min, and max launch time for the daemons. SLURM block launches the daemon, so you only get the time to launch the daemons and the total time to launch the job. Ditto for bproc. TM looks more like rsh. Only those four environments are currently supported - anyone interested in extending this capability to other environs is welcome to do so. In all cases, you also get the time to setup the job for launch.
OMPI_MCA_ompi_timing: set it to anything non-zero and you will get the time for mpi_init to reach the compound registry command, the time to execute that command, the time to go from our stage1 barrier to the stage2 barrier, and the time to go from the stage2 barrier to the end of mpi_init. This will be output for each process, so you'll have to compile any statistics on your own. Note: if someone develops a nice parser to do so, it would be really appreciated if you could/would share!
This commit was SVN r12302.
2006-10-25 19:27:47 +04:00
|
|
|
}
|
2006-11-03 19:04:40 +03:00
|
|
|
|
2009-04-27 18:15:33 +04:00
|
|
|
/* If desired, send a notifier message that we've finished MPI_INIT */
|
|
|
|
if (ompi_notify_init_finalize) {
|
|
|
|
orte_notifier.log(ORTE_NOTIFIER_NOTICE,
|
|
|
|
ORTE_SUCCESS,
|
|
|
|
"MPI_INIT:Finishing on host %s, pid %d",
|
|
|
|
orte_process_info.nodename,
|
|
|
|
orte_process_info.pid);
|
|
|
|
}
|
|
|
|
|
2004-02-13 16:56:55 +03:00
|
|
|
return MPI_SUCCESS;
|
2004-01-15 09:08:25 +03:00
|
|
|
}
|