2004-01-15 09:08:25 +03:00
|
|
|
/*
|
2005-11-05 22:57:48 +03:00
|
|
|
* Copyright (c) 2004-2005 The Trustees of Indiana University and Indiana
|
|
|
|
* University Research and Technology
|
|
|
|
* Corporation. All rights reserved.
|
|
|
|
* Copyright (c) 2004-2005 The University of Tennessee and The University
|
|
|
|
* 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.
|
2006-08-04 18:41:31 +04:00
|
|
|
* Copyright (c) 2006 Cisco Systems, Inc. All rights reserved.
|
2006-11-22 05:06:52 +03:00
|
|
|
* Copyright (c) 2006 Los Alamos National Security, LLC. All rights
|
|
|
|
* reserved.
|
|
|
|
*
|
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 */
|
|
|
|
|
2004-01-15 09:08:25 +03:00
|
|
|
#include "mpi.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"
|
2005-07-04 06:38:44 +04:00
|
|
|
#include "opal/util/show_help.h"
|
|
|
|
#include "opal/util/stacktrace.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-27 01:03:41 +04:00
|
|
|
#include "orte/util/sys_info.h"
|
2005-08-16 20:17:52 +04:00
|
|
|
#include "orte/util/proc_info.h"
|
|
|
|
#include "orte/util/session_dir.h"
|
|
|
|
#include "orte/runtime/runtime.h"
|
|
|
|
#include "orte/mca/oob/oob.h"
|
|
|
|
#include "orte/mca/oob/base/base.h"
|
|
|
|
#include "orte/mca/ns/ns.h"
|
2005-08-16 21:18:56 +04:00
|
|
|
#include "orte/mca/ns/base/base.h"
|
2005-08-16 20:17:52 +04:00
|
|
|
#include "orte/mca/gpr/gpr.h"
|
|
|
|
#include "orte/mca/rml/rml.h"
|
|
|
|
#include "orte/mca/schema/schema.h"
|
2006-08-16 20:35:09 +04:00
|
|
|
#include "orte/mca/smr/smr.h"
|
2005-08-16 20:17:52 +04:00
|
|
|
#include "orte/mca/errmgr/errmgr.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"
|
|
|
|
#include "ompi/communicator/communicator.h"
|
|
|
|
#include "ompi/group/group.h"
|
|
|
|
#include "ompi/info/info.h"
|
|
|
|
#include "ompi/errhandler/errcode.h"
|
|
|
|
#include "ompi/errhandler/errclass.h"
|
|
|
|
#include "ompi/request/request.h"
|
|
|
|
#include "ompi/op/op.h"
|
|
|
|
#include "ompi/file/file.h"
|
|
|
|
#include "ompi/attribute/attribute.h"
|
|
|
|
#include "ompi/mca/allocator/base/base.h"
|
|
|
|
#include "ompi/mca/allocator/allocator.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/mpool/mpool.h"
|
|
|
|
#include "ompi/mca/pml/pml.h"
|
|
|
|
#include "ompi/mca/pml/base/pml_base_module_exchange.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/coll.h"
|
|
|
|
#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"
|
2005-08-16 20:17:52 +04:00
|
|
|
|
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;
|
|
|
|
|
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__);
|
|
|
|
|
|
|
|
|
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;
|
2005-03-25 06:06:06 +03:00
|
|
|
bool compound_cmd = false;
|
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;
|
2005-08-30 21:34:23 +04:00
|
|
|
|
2005-03-25 06:06:06 +03:00
|
|
|
/* Join the run-time environment - do the things that don't hit
|
|
|
|
the registry */
|
|
|
|
|
2005-05-23 18:50:52 +04:00
|
|
|
if (ORTE_SUCCESS != (ret = opal_init())) {
|
|
|
|
error = "ompi_mpi_init: opal_init failed";
|
|
|
|
goto error;
|
|
|
|
}
|
2005-08-16 20:17:52 +04:00
|
|
|
|
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
|
|
|
}
|
|
|
|
|
2005-08-27 00:13:35 +04:00
|
|
|
/* Setup ORTE stage 1, note that we are not infrastructre */
|
2005-05-23 18:50:52 +04:00
|
|
|
|
2005-08-27 00:13:35 +04:00
|
|
|
if (ORTE_SUCCESS != (ret = orte_init_stage1(false))) {
|
2005-03-23 20:50:12 +03:00
|
|
|
error = "ompi_mpi_init: orte_init_stage1 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
|
|
|
}
|
|
|
|
|
2005-03-27 17:05:23 +04:00
|
|
|
/* If we are not the seed nor a singleton, AND we have not set the
|
|
|
|
orte_debug flag, then start recording the compound command that
|
|
|
|
starts us up. if we are the seed or a singleton, then don't do
|
|
|
|
this - the registry is local, so we'll just drive it
|
|
|
|
directly */
|
|
|
|
|
2005-03-23 20:50:12 +03:00
|
|
|
if (orte_process_info.seed ||
|
|
|
|
NULL == orte_process_info.ns_replica ||
|
|
|
|
orte_debug_flag) {
|
|
|
|
compound_cmd = false;
|
|
|
|
} else {
|
|
|
|
if (ORTE_SUCCESS != (ret = orte_gpr.begin_compound_cmd())) {
|
|
|
|
ORTE_ERROR_LOG(ret);
|
|
|
|
error = "ompi_mpi_init: orte_gpr.begin_compound_cmd failed";
|
|
|
|
goto error;
|
|
|
|
}
|
|
|
|
compound_cmd = true;
|
|
|
|
}
|
2004-09-23 18:35:02 +04:00
|
|
|
|
2005-03-23 20:50:12 +03:00
|
|
|
/* Now do the things that hit the registry */
|
2005-03-27 17:05:23 +04:00
|
|
|
|
2005-03-23 20:50:12 +03:00
|
|
|
if (ORTE_SUCCESS != (ret = orte_init_stage2())) {
|
|
|
|
ORTE_ERROR_LOG(ret);
|
|
|
|
error = "ompi_mpi_init: orte_init_stage2 failed";
|
|
|
|
goto error;
|
|
|
|
}
|
2005-03-27 17:05:23 +04:00
|
|
|
|
2006-11-03 19:04:40 +03:00
|
|
|
/* check for timing request - get stop time and report elapsed time if so */
|
|
|
|
if (timing) {
|
|
|
|
gettimeofday(&ompistop, NULL);
|
|
|
|
opal_output(0, "ompi_mpi_init [%ld]: time from start to completion of orte_init %ld usec",
|
|
|
|
(long)ORTE_PROC_MY_NAME->vpid,
|
|
|
|
(long int)((ompistop.tv_sec - ompistart.tv_sec)*1000000 +
|
|
|
|
(ompistop.tv_usec - ompistart.tv_usec)));
|
|
|
|
gettimeofday(&ompistart, NULL);
|
|
|
|
}
|
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
|
|
|
}
|
|
|
|
|
2005-08-16 20:17:52 +04:00
|
|
|
/* Setup process affinity */
|
|
|
|
|
|
|
|
if (ompi_mpi_paffinity_alone) {
|
2005-08-16 21:18:56 +04:00
|
|
|
bool set = false;
|
2005-08-16 20:17:52 +04:00
|
|
|
param = mca_base_param_find("mpi", NULL, "paffinity_processor");
|
|
|
|
if (param >= 0) {
|
2005-08-16 21:18:56 +04:00
|
|
|
if (OMPI_SUCCESS == mca_base_param_lookup_int(param, &value)) {
|
|
|
|
if (value >= 0) {
|
|
|
|
if (OPAL_SUCCESS == opal_paffinity_base_set(value)) {
|
|
|
|
set = true;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
if (!set) {
|
|
|
|
char *vpid;
|
Bring over the update to terminate orteds that are generated by a dynamic spawn such as comm_spawn. This introduces the concept of a job "family" - i.e., jobs that have a parent/child relationship. Comm_spawn'ed jobs have a parent (the one that spawned them). We track that relationship throughout the lineage - i.e., if a comm_spawned job in turn calls comm_spawn, then it has a parent (the one that spawned it) and a "root" job (the original job that started things).
Accordingly, there are new APIs to the name service to support the ability to get a job's parent, root, immediate children, and all its descendants. In addition, the terminate_job, terminate_orted, and signal_job APIs for the PLS have been modified to accept attributes that define the extent of their actions. For example, doing a "terminate_job" with an attribute of ORTE_NS_INCLUDE_DESCENDANTS will terminate the given jobid AND all jobs that descended from it.
I have tested this capability on a MacBook under rsh, Odin under SLURM, and LANL's Flash (bproc). It worked successfully on non-MPI jobs (both simple and including a spawn), and MPI jobs (again, both simple and with a spawn).
This commit was SVN r12597.
2006-11-14 22:34:59 +03:00
|
|
|
orte_ns.get_vpid_string(&vpid, orte_process_info.my_name);
|
2005-08-16 21:18:56 +04:00
|
|
|
opal_show_help("help-mpi-runtime",
|
|
|
|
"mpi_init:startup:paffinity-unavailable",
|
|
|
|
true, vpid);
|
|
|
|
free(vpid);
|
2005-08-16 20:17:52 +04:00
|
|
|
}
|
2005-08-26 14:56:39 +04:00
|
|
|
|
|
|
|
/* If we were able to set processor affinity, try setting
|
|
|
|
up memory affinity */
|
|
|
|
|
|
|
|
else {
|
|
|
|
if (OPAL_SUCCESS == opal_maffinity_base_open() &&
|
|
|
|
OPAL_SUCCESS == opal_maffinity_base_select()) {
|
|
|
|
ompi_mpi_maffinity_setup = true;
|
|
|
|
}
|
|
|
|
}
|
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
|
|
|
*/
|
|
|
|
if (OMPI_SUCCESS != (ret = ompi_ddt_init())) {
|
|
|
|
error = "ompi_ddt_init() failed";
|
|
|
|
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
|
|
|
}
|
|
|
|
|
2005-10-25 22:33:48 +04:00
|
|
|
/* initialize ops. This has to be done *after* ddt_init, but
|
|
|
|
befor mca_coll_base_open, since come collective modules
|
|
|
|
(e.g. the hierarchical) need them in the query function
|
|
|
|
*/
|
|
|
|
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;
|
|
|
|
}
|
|
|
|
|
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. */
|
|
|
|
|
|
|
|
/* Initialize module exchange */
|
|
|
|
|
2005-08-05 22:03:30 +04:00
|
|
|
if (OMPI_SUCCESS != (ret = mca_pml_base_modex_init())) {
|
|
|
|
error = "mca_pml_base_modex_init() failed";
|
2004-10-15 00:50:06 +04:00
|
|
|
goto error;
|
|
|
|
}
|
|
|
|
|
2005-03-27 17:05:23 +04:00
|
|
|
/* 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 !=
|
2005-03-27 17:05:23 +04:00
|
|
|
(ret = mca_mpool_base_init(OMPI_ENABLE_PROGRESS_THREADS,
|
|
|
|
OMPI_ENABLE_MPI_THREADS))) {
|
|
|
|
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 !=
|
|
|
|
(ret = mca_pml_base_select(OMPI_ENABLE_PROGRESS_THREADS,
|
|
|
|
OMPI_ENABLE_MPI_THREADS))) {
|
|
|
|
error = "mca_pml_base_select() failed";
|
|
|
|
goto error;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (OMPI_SUCCESS !=
|
|
|
|
(ret = mca_coll_base_find_available(OMPI_ENABLE_PROGRESS_THREADS,
|
|
|
|
OMPI_ENABLE_MPI_THREADS))) {
|
|
|
|
error = "mca_coll_base_find_available() failed";
|
|
|
|
goto error;
|
|
|
|
}
|
|
|
|
|
2006-01-28 18:38:37 +03:00
|
|
|
if (OMPI_SUCCESS !=
|
|
|
|
(ret = ompi_osc_base_find_available(OMPI_ENABLE_PROGRESS_THREADS,
|
|
|
|
OMPI_ENABLE_MPI_THREADS))) {
|
|
|
|
error = "ompi_osc_base_find_available() failed";
|
|
|
|
goto error;
|
|
|
|
}
|
|
|
|
|
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 error classes */
|
|
|
|
if (OMPI_SUCCESS != (ret = ompi_errclass_init())) {
|
|
|
|
error = "ompi_errclass_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-09-05 20:05:37 +04:00
|
|
|
/* do module exchange */
|
2005-08-05 22:03:30 +04:00
|
|
|
if (OMPI_SUCCESS != (ret = mca_pml_base_modex_exchange())) {
|
|
|
|
error = "mca_pml_base_modex_exchange() failed";
|
2004-09-05 20:05:37 +04:00
|
|
|
goto error;
|
|
|
|
}
|
|
|
|
|
2005-03-27 17:05:23 +04:00
|
|
|
/* Let system know we are at STG1 Barrier */
|
2006-08-16 20:35:09 +04:00
|
|
|
if (ORTE_SUCCESS != (ret = orte_smr.set_proc_state(orte_process_info.my_name,
|
2005-03-14 23:57:21 +03:00
|
|
|
ORTE_PROC_STATE_AT_STG1, 0))) {
|
|
|
|
ORTE_ERROR_LOG(ret);
|
|
|
|
error = "set process state failed";
|
2004-11-20 22:12:43 +03:00
|
|
|
goto error;
|
2005-03-14 23:57:21 +03:00
|
|
|
}
|
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 */
|
|
|
|
if (timing) {
|
2006-11-03 19:04:40 +03:00
|
|
|
gettimeofday(&ompistop, NULL);
|
|
|
|
opal_output(0, "ompi_mpi_init[%ld]: time from completion of orte_init to exec_compound_cmd %ld usec",
|
|
|
|
(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
|
|
|
}
|
|
|
|
|
2005-03-27 17:05:23 +04:00
|
|
|
/* if the compound command is operative, execute it */
|
|
|
|
|
2005-03-23 20:50:12 +03:00
|
|
|
if (compound_cmd) {
|
|
|
|
if (OMPI_SUCCESS != (ret = orte_gpr.exec_compound_cmd())) {
|
|
|
|
ORTE_ERROR_LOG(ret);
|
2005-08-16 20:17:52 +04:00
|
|
|
error = "ompi_rte_init: orte_gpr.exec_compound_cmd failed";
|
|
|
|
goto error;
|
2005-03-23 20:50:12 +03:00
|
|
|
}
|
2005-03-14 23:57:21 +03:00
|
|
|
}
|
2005-03-23 20:50:12 +03:00
|
|
|
|
2006-09-29 17:19:44 +04:00
|
|
|
/* check for timing request - get stop time and report elapsed time if so */
|
|
|
|
if (timing) {
|
2006-11-03 19:04:40 +03:00
|
|
|
gettimeofday(&ompistop, NULL);
|
|
|
|
opal_output(0, "ompi_mpi_init[%ld]: time to execute compound command %ld usec",
|
|
|
|
(long)ORTE_PROC_MY_NAME->vpid,
|
|
|
|
(long int)((ompistop.tv_sec - ompistart.tv_sec)*1000000 +
|
|
|
|
(ompistop.tv_usec - ompistart.tv_usec)));
|
2006-11-30 18:06:40 +03:00
|
|
|
gettimeofday(&ompistart, NULL);
|
2006-09-29 17:19:44 +04:00
|
|
|
}
|
|
|
|
|
2006-11-28 03:06:25 +03:00
|
|
|
/* FIRST BARRIER - WAIT FOR MSG FROM RMGR_PROC_STAGE_GATE_MGR TO ARRIVE.
|
|
|
|
* We pass a "process_first" flag of "true" to indicate that we need to
|
|
|
|
* process the STG1 message prior to sending it along the xcast chain
|
|
|
|
* as this message contains all the oob contact info we need!
|
|
|
|
*/
|
|
|
|
if (ORTE_SUCCESS != (ret = orte_rml.xcast(ORTE_PROC_MY_NAME->jobid, true,
|
|
|
|
NULL, orte_gpr.deliver_notify_msg))) {
|
2005-03-14 23:57:21 +03:00
|
|
|
ORTE_ERROR_LOG(ret);
|
2005-08-16 20:17:52 +04:00
|
|
|
error = "ompi_mpi_init: failed to see all procs register\n";
|
|
|
|
goto error;
|
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 start time */
|
|
|
|
if (timing) {
|
2006-11-30 18:06:40 +03:00
|
|
|
gettimeofday(&ompistop, NULL);
|
|
|
|
opal_output(0, "ompi_mpi_init[%ld]: time to execute xcast %ld usec",
|
|
|
|
(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
|
|
|
}
|
2006-11-03 19:04:40 +03:00
|
|
|
|
2005-07-12 09:40:56 +04:00
|
|
|
/* start PTL's */
|
|
|
|
ret = MCA_PML_CALL(enable(true));
|
|
|
|
if( OMPI_SUCCESS != ret ) {
|
|
|
|
error = "PML control failed";
|
|
|
|
goto error;
|
|
|
|
}
|
|
|
|
|
2004-09-05 20:05:37 +04:00
|
|
|
/* add all ompi_proc_t's to PML */
|
|
|
|
if (NULL == (procs = ompi_proc_world(&nprocs))) {
|
|
|
|
error = "ompi_proc_world() failed";
|
|
|
|
goto error;
|
|
|
|
}
|
2005-07-12 09:40:56 +04:00
|
|
|
ret = MCA_PML_CALL(add_procs(procs, nprocs));
|
|
|
|
free(procs);
|
|
|
|
if( OMPI_SUCCESS != ret ) {
|
2004-09-05 20:05:37 +04:00
|
|
|
error = "PML add procs failed";
|
|
|
|
goto error;
|
|
|
|
}
|
|
|
|
|
2005-05-24 02:06:50 +04:00
|
|
|
MCA_PML_CALL(add_comm(&ompi_mpi_comm_world));
|
|
|
|
MCA_PML_CALL(add_comm(&ompi_mpi_comm_self));
|
|
|
|
|
2005-03-27 17:05:23 +04: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. */
|
2004-02-05 04:52:56 +03:00
|
|
|
|
2004-06-07 19:33:53 +04:00
|
|
|
ompi_mpi_thread_requested = requested;
|
2005-04-14 22:55:53 +04:00
|
|
|
if (OMPI_HAVE_THREAD_SUPPORT == 0) {
|
2005-03-27 17:05:23 +04:00
|
|
|
ompi_mpi_thread_provided = *provided = MPI_THREAD_SINGLE;
|
|
|
|
ompi_mpi_main_thread = NULL;
|
|
|
|
} else if (OMPI_ENABLE_MPI_THREADS == 1) {
|
|
|
|
ompi_mpi_thread_provided = *provided = requested;
|
2005-07-04 02:45:48 +04:00
|
|
|
ompi_mpi_main_thread = opal_thread_get_self();
|
2005-03-27 17:05:23 +04:00
|
|
|
} else {
|
|
|
|
if (MPI_THREAD_MULTIPLE == requested) {
|
|
|
|
ompi_mpi_thread_provided = *provided = MPI_THREAD_SERIALIZED;
|
|
|
|
} else {
|
|
|
|
ompi_mpi_thread_provided = *provided = requested;
|
|
|
|
}
|
2005-07-04 02:45:48 +04:00
|
|
|
ompi_mpi_main_thread = opal_thread_get_self();
|
2005-03-27 17:05:23 +04:00
|
|
|
}
|
|
|
|
|
2004-06-29 04:02:25 +04:00
|
|
|
ompi_mpi_thread_multiple = (ompi_mpi_thread_provided ==
|
|
|
|
MPI_THREAD_MULTIPLE);
|
2006-08-15 19:55:53 +04:00
|
|
|
if ((OMPI_ENABLE_PROGRESS_THREADS == 1) ||
|
|
|
|
(*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
|
|
|
|
2004-05-08 03:23:03 +04:00
|
|
|
/* Init coll for the comms */
|
|
|
|
|
2004-09-05 20:05:37 +04:00
|
|
|
if (OMPI_SUCCESS !=
|
|
|
|
(ret = mca_coll_base_comm_select(MPI_COMM_WORLD, NULL))) {
|
|
|
|
error = "mca_coll_base_comm_select(MPI_COMM_WORLD) failed";
|
|
|
|
goto error;
|
2004-07-13 16:35:43 +04:00
|
|
|
}
|
2004-05-08 03:23:03 +04:00
|
|
|
|
2005-11-12 06:47:17 +03:00
|
|
|
if (OMPI_SUCCESS !=
|
|
|
|
(ret = mca_coll_base_comm_select(MPI_COMM_SELF, NULL))) {
|
|
|
|
error = "mca_coll_base_comm_select(MPI_COMM_SELF) failed";
|
|
|
|
goto error;
|
|
|
|
}
|
|
|
|
|
2005-04-09 23:34:32 +04:00
|
|
|
#if OMPI_ENABLE_PROGRESS_THREADS && 0
|
|
|
|
/* BWB - XXX - FIXME - is this actually correct? */
|
2005-01-13 18:30:49 +03:00
|
|
|
/* setup I/O forwarding */
|
2005-04-09 23:34:32 +04:00
|
|
|
if (orte_process_info.seed == false) {
|
2005-01-18 20:32:54 +03:00
|
|
|
if (OMPI_SUCCESS != (ret = ompi_mpi_init_io())) {
|
2005-08-16 20:17:52 +04:00
|
|
|
error = "ompi_rte_init_io failed";
|
|
|
|
goto error;
|
2005-01-18 20:32:54 +03:00
|
|
|
}
|
2005-01-13 18:30:49 +03:00
|
|
|
}
|
2004-11-18 02:37:49 +03:00
|
|
|
#endif
|
2004-05-08 03:23:03 +04:00
|
|
|
|
2005-07-09 01:01:37 +04:00
|
|
|
/*
|
|
|
|
* Dump all MCA parameters if requested
|
|
|
|
*/
|
|
|
|
if (ompi_mpi_show_mca_params) {
|
|
|
|
ompi_show_all_mca_params(ompi_mpi_comm_world.c_my_rank,
|
|
|
|
nprocs,
|
|
|
|
orte_system_info.nodename);
|
|
|
|
}
|
|
|
|
|
2005-03-27 17:05:23 +04:00
|
|
|
/* Let system know we are at STG2 Barrier */
|
|
|
|
|
2006-08-16 20:35:09 +04:00
|
|
|
if (ORTE_SUCCESS != (ret = orte_smr.set_proc_state(orte_process_info.my_name,
|
2005-03-14 23:57:21 +03:00
|
|
|
ORTE_PROC_STATE_AT_STG2, 0))) {
|
|
|
|
ORTE_ERROR_LOG(ret);
|
|
|
|
error = "set process state failed";
|
|
|
|
goto error;
|
2005-02-21 21:56:30 +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 */
|
|
|
|
if (timing) {
|
2006-11-03 19:04:40 +03:00
|
|
|
gettimeofday(&ompistop, NULL);
|
|
|
|
opal_output(0, "ompi_mpi_init[%ld]: time from stage1 to stage2 %ld usec",
|
|
|
|
(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
|
|
|
}
|
|
|
|
|
2005-03-27 17:05:23 +04:00
|
|
|
/* Second barrier -- wait for message from
|
|
|
|
RMGR_PROC_STAGE_GATE_MGR to arrive */
|
|
|
|
|
2006-11-28 03:06:25 +03:00
|
|
|
if (ORTE_SUCCESS != (ret = orte_rml.xcast(ORTE_PROC_MY_NAME->jobid, false,
|
|
|
|
NULL, orte_gpr.deliver_notify_msg))) {
|
2005-03-14 23:57:21 +03:00
|
|
|
ORTE_ERROR_LOG(ret);
|
|
|
|
error = "ompi_mpi_init: failed to see all procs register\n";
|
|
|
|
goto error;
|
|
|
|
}
|
|
|
|
|
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 start time */
|
|
|
|
if (timing) {
|
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
|
|
|
}
|
|
|
|
|
2004-09-29 16:41:55 +04:00
|
|
|
/* new very last step: check whether we have been spawned or not.
|
|
|
|
We introduce that at the very end, since we need collectives,
|
2005-03-27 17:05:23 +04:00
|
|
|
datatypes, ptls etc. up and running here.... */
|
|
|
|
|
2004-09-29 16:41:55 +04:00
|
|
|
if (OMPI_SUCCESS != (ret = ompi_comm_dyn_init())) {
|
|
|
|
error = "ompi_comm_dyn_init() failed";
|
|
|
|
goto error;
|
|
|
|
}
|
|
|
|
|
2004-09-05 20:05:37 +04:00
|
|
|
error:
|
|
|
|
if (ret != OMPI_SUCCESS) {
|
2005-10-18 00:47:44 +04:00
|
|
|
const char *err_msg = opal_strerror(ret);
|
2005-07-04 06:38:44 +04:00
|
|
|
opal_show_help("help-mpi-runtime",
|
2004-09-05 20:05:37 +04:00
|
|
|
"mpi_init:startup:internal-failure", true,
|
2005-10-18 00:47:44 +04:00
|
|
|
"MPI_INIT", "MPI_INIT", error, err_msg, ret);
|
2004-09-05 20:05:37 +04:00
|
|
|
return ret;
|
2004-06-29 04:02:25 +04:00
|
|
|
}
|
2004-05-08 03:23:03 +04:00
|
|
|
|
2006-08-02 02:23:57 +04:00
|
|
|
#if OMPI_ENABLE_PROGRESS_THREADS == 0
|
|
|
|
/* switch from letting us sit in the event library for a bit each
|
|
|
|
time through opal_progress() to completely non-blocking */
|
2006-11-22 05:06:52 +03:00
|
|
|
opal_progress_set_event_flag(OPAL_EVLOOP_NONBLOCK);
|
2006-08-02 02:23:57 +04:00
|
|
|
#endif
|
|
|
|
|
2006-11-22 05:06:52 +03:00
|
|
|
/* Undo ORTE calling opal_progress_event_users_increment() during
|
|
|
|
MPI lifetime, to get better latency when not using TCP */
|
|
|
|
opal_progress_event_users_decrement();
|
|
|
|
|
|
|
|
/* override ORTE setting yield_when_idle, if desired */
|
|
|
|
param = mca_base_param_find("mpi", NULL, "yield_when_idle");
|
|
|
|
mca_base_param_lookup_int(param, &value);
|
|
|
|
if (value < 0) {
|
|
|
|
/* if we got a bogus value, do the conservative thing... */
|
|
|
|
opal_progress_set_yield_when_idle(true);
|
|
|
|
} else {
|
|
|
|
opal_progress_set_yield_when_idle(value == 0 ? false : true);
|
2006-08-04 18:41: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);
|
|
|
|
}
|
|
|
|
|
2006-08-04 18:41:31 +04:00
|
|
|
|
|
|
|
/* If we want the connection warmup, go do it */
|
|
|
|
if (ompi_mpi_preconnect_all) {
|
|
|
|
if (OMPI_SUCCESS != (ret = ompi_init_do_preconnect())) {
|
|
|
|
error = "ompi_mpi_do_preconnect_all() failed";
|
|
|
|
/* This will loop back up above, but ret != OMPI_SUCCESS,
|
|
|
|
so we'll end up returning out of this function before
|
|
|
|
getting here (and therefore avoiding an infinite
|
|
|
|
loop) */
|
|
|
|
goto error;
|
|
|
|
}
|
2005-03-30 05:40:26 +04:00
|
|
|
}
|
|
|
|
|
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
|
|
|
|
2005-03-14 23:57:21 +03:00
|
|
|
if (orte_debug_flag) {
|
2005-08-16 20:17:52 +04:00
|
|
|
opal_output(0, "[%lu,%lu,%lu] ompi_mpi_init completed",
|
|
|
|
ORTE_NAME_ARGS(orte_process_info.my_name));
|
2004-11-20 22:12:43 +03:00
|
|
|
}
|
|
|
|
|
2005-09-20 19:22:15 +04:00
|
|
|
/* Do we need to wait for a TotalView-like debugger? */
|
|
|
|
ompi_wait_for_totalview();
|
|
|
|
|
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 */
|
|
|
|
if (timing) {
|
2006-11-03 19:04:40 +03:00
|
|
|
gettimeofday(&ompistop, NULL);
|
|
|
|
opal_output(0, "ompi_mpi_init[%ld]: time from stage2 xcast to complete mpi_init %ld usec",
|
|
|
|
(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
|
|
|
|
2004-02-13 16:56:55 +03:00
|
|
|
return MPI_SUCCESS;
|
2004-01-15 09:08:25 +03:00
|
|
|
}
|