1
1
openmpi/opal/runtime/opal_params.c

121 строка
4.1 KiB
C
Исходник Обычный вид История

/*
* 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.
* Copyright (c) 2004-2005 High Performance Computing Center Stuttgart,
* University of Stuttgart. All rights reserved.
* Copyright (c) 2004-2005 The Regents of the University of California.
* All rights reserved.
* Copyright (c) 2006 Los Alamos National Security, LLC. All rights
* reserved.
Per RFC, bring in the following changes: * Remove paffinity, maffinity, and carto frameworks -- they've been wholly replaced by hwloc. * Move ompi_mpi_init() affinity-setting/checking code down to ORTE. * Update sm, smcuda, wv, and openib components to no longer use carto. Instead, use hwloc data. There are still optimizations possible in the sm/smcuda BTLs (i.e., making multiple mpools). Also, the old carto-based code found out how many NUMA nodes were ''available'' -- not how many were used ''in this job''. The new hwloc-using code computes the same value -- it was not updated to calculate how many NUMA nodes are used ''by this job.'' * Note that I cannot compile the smcuda and wv BTLs -- I ''think'' they're right, but they need to be verified by their owners. * The openib component now does a bunch of stuff to figure out where "near" OpenFabrics devices are. '''THIS IS A CHANGE IN DEFAULT BEHAVIOR!!''' and still needs to be verified by OpenFabrics vendors (I do not have a NUMA machine with an OpenFabrics device that is a non-uniform distance from multiple different NUMA nodes). * Completely rewrite the OMPI_Affinity_str() routine from the "affinity" mpiext extension. This extension now understands hyperthreads; the output format of it has changed a bit to reflect this new information. * Bunches of minor changes around the code base to update names/types from maffinity/paffinity-based names to hwloc-based names. * Add some helper functions into the hwloc base, mainly having to do with the fact that we have the hwloc data reporting ''all'' topology information, but sometimes you really only want the (online | available) data. This commit was SVN r26391.
2012-05-07 18:52:54 +04:00
* Copyright (c) 2008-2012 Cisco Systems, Inc. All rights reserved.
- Split the datatype engine into two parts: an MPI specific part in OMPI and a language agnostic part in OPAL. The convertor is completely moved into OPAL. This offers several benefits as described in RFC http://www.open-mpi.org/community/lists/devel/2009/07/6387.php namely: - Fewer basic types (int* and float* types, boolean and wchar - Fixing naming scheme to ompi-nomenclature. - Usability outside of the ompi-layer. - Due to the fixed nature of simple opal types, their information is completely known at compile time and therefore constified - With fewer datatypes (22), the actual sizes of bit-field types may be reduced from 64 to 32 bits, allowing reorganizing the opal_datatype structure, eliminating holes and keeping data required in convertor (upon send/recv) in one cacheline... This has implications to the convertor-datastructure and other parts of the code. - Several performance tests have been run, the netpipe latency does not change with this patch on Linux/x86-64 on the smoky cluster. - Extensive tests have been done to verify correctness (no new regressions) using: 1. mpi_test_suite on linux/x86-64 using clean ompi-trunk and ompi-ddt: a. running both trunk and ompi-ddt resulted in no differences (except for MPI_SHORT_INT and MPI_TYPE_MIX_LB_UB do now run correctly). b. with --enable-memchecker and running under valgrind (one buglet when run with static found in test-suite, commited) 2. ibm testsuite on linux/x86-64 using clean ompi-trunk and ompi-ddt: all passed (except for the dynamic/ tests failed!! as trunk/MTT) 3. compilation and usage of HDF5 tests on Jaguar using PGI and PathScale compilers. 4. compilation and usage on Scicortex. - Please note, that for the heterogeneous case, (-m32 compiled binaries/ompi), neither ompi-trunk, nor ompi-ddt branch would successfully launch. This commit was SVN r21641.
2009-07-13 08:56:31 +04:00
* Copyright (c) 2009 Oak Ridge National Labs. All rights reserved.
* Copyright (c) 2010 Los Alamos National Security, LLC.
* All rights reserved.
* $COPYRIGHT$
*
* Additional copyrights may follow
*
* $HEADER$
*/
#include "opal_config.h"
#include <time.h>
#ifdef HAVE_SIGNAL_H
#include <signal.h>
#endif
#include "opal/constants.h"
#include "opal/runtime/opal.h"
- Split the datatype engine into two parts: an MPI specific part in OMPI and a language agnostic part in OPAL. The convertor is completely moved into OPAL. This offers several benefits as described in RFC http://www.open-mpi.org/community/lists/devel/2009/07/6387.php namely: - Fewer basic types (int* and float* types, boolean and wchar - Fixing naming scheme to ompi-nomenclature. - Usability outside of the ompi-layer. - Due to the fixed nature of simple opal types, their information is completely known at compile time and therefore constified - With fewer datatypes (22), the actual sizes of bit-field types may be reduced from 64 to 32 bits, allowing reorganizing the opal_datatype structure, eliminating holes and keeping data required in convertor (upon send/recv) in one cacheline... This has implications to the convertor-datastructure and other parts of the code. - Several performance tests have been run, the netpipe latency does not change with this patch on Linux/x86-64 on the smoky cluster. - Extensive tests have been done to verify correctness (no new regressions) using: 1. mpi_test_suite on linux/x86-64 using clean ompi-trunk and ompi-ddt: a. running both trunk and ompi-ddt resulted in no differences (except for MPI_SHORT_INT and MPI_TYPE_MIX_LB_UB do now run correctly). b. with --enable-memchecker and running under valgrind (one buglet when run with static found in test-suite, commited) 2. ibm testsuite on linux/x86-64 using clean ompi-trunk and ompi-ddt: all passed (except for the dynamic/ tests failed!! as trunk/MTT) 3. compilation and usage of HDF5 tests on Jaguar using PGI and PathScale compilers. 4. compilation and usage on Scicortex. - Please note, that for the heterogeneous case, (-m32 compiled binaries/ompi), neither ompi-trunk, nor ompi-ddt branch would successfully launch. This commit was SVN r21641.
2009-07-13 08:56:31 +04:00
#include "opal/datatype/opal_datatype.h"
#include "opal/mca/base/mca_base_param.h"
#include "opal/threads/mutex.h"
#include "opal/threads/threads.h"
#include "opal/mca/shmem/base/base.h"
int opal_register_params(void)
{
Brice Goglin noticed that mpi_paffinity_alone didn't seem to be doing anything for non-MPI apps. Oops! (But before you freak out, gentle reader, note that mpi_paffinity_alone for MPI apps still worked fine) When we made the switchover somewhere in the 1.3 series to have the orted's do processor binding, then stuff like: mpirun --mca mpi_paffinity_alone 1 hostname should have bound hostname to processor 0. But it didn't because of a subtle startup ordering issue: the MCA param registration for opal_paffinity_alone was in the paffinity base (vs. being in opal/runtime/opal_params.c), but it didn't actually get registered until after the global variable opal_paffinity_alone was checked to see if we wanted old-style affinity bindings. Oops. However, for MPI apps, even though the orted didn't do the binding, ompi_mpi_init() would notice that opal_paffinity_alone was set, yet the process didn't seem to be bound. So the MPI process would bind itself (this was done to support the running-without-orteds scenarios). Hence, MPI apps still obeyed mpi_paffinity_alone semantics. But note that the error described above caused the new mpirun switch --report-bindings to not work with mpi_paffinity_alone=1, meaning that the orted would not report the bindings when mpi_paffinity_alone was set to 1 (it ''did'' correctly report bindings if you used --bind-to-core or one of the other binding options). This commit separates out the paffinity base MCA param registration into a small function that can be called at the Right place during the startup sequence. This commit was SVN r22602.
2010-02-11 01:32:00 +03:00
int ret;
#if OPAL_ENABLE_DEBUG
int value;
#endif /* OPAL_ENABLE_DEBUG */
Brice Goglin noticed that mpi_paffinity_alone didn't seem to be doing anything for non-MPI apps. Oops! (But before you freak out, gentle reader, note that mpi_paffinity_alone for MPI apps still worked fine) When we made the switchover somewhere in the 1.3 series to have the orted's do processor binding, then stuff like: mpirun --mca mpi_paffinity_alone 1 hostname should have bound hostname to processor 0. But it didn't because of a subtle startup ordering issue: the MCA param registration for opal_paffinity_alone was in the paffinity base (vs. being in opal/runtime/opal_params.c), but it didn't actually get registered until after the global variable opal_paffinity_alone was checked to see if we wanted old-style affinity bindings. Oops. However, for MPI apps, even though the orted didn't do the binding, ompi_mpi_init() would notice that opal_paffinity_alone was set, yet the process didn't seem to be bound. So the MPI process would bind itself (this was done to support the running-without-orteds scenarios). Hence, MPI apps still obeyed mpi_paffinity_alone semantics. But note that the error described above caused the new mpirun switch --report-bindings to not work with mpi_paffinity_alone=1, meaning that the orted would not report the bindings when mpi_paffinity_alone was set to 1 (it ''did'' correctly report bindings if you used --bind-to-core or one of the other binding options). This commit separates out the paffinity base MCA param registration into a small function that can be called at the Right place during the startup sequence. This commit was SVN r22602.
2010-02-11 01:32:00 +03:00
/*
* This string is going to be used in opal/util/stacktrace.c
*/
{
char *string = NULL;
int j;
int signals[] = {
#ifdef SIGABRT
SIGABRT,
#endif
#ifdef SIGBUS
SIGBUS,
#endif
#ifdef SIGFPE
SIGFPE,
#endif
#ifdef SIGSEGV
SIGSEGV,
#endif
-1
};
for (j = 0 ; signals[j] != -1 ; ++j) {
if (j == 0) {
asprintf(&string, "%d", signals[j]);
} else {
char *tmp;
asprintf(&tmp, "%s,%d", string, signals[j]);
free(string);
string = tmp;
}
}
mca_base_param_reg_string_name("opal", "signal",
"Comma-delimited list of integer signal numbers to Open MPI to attempt to intercept. Upon receipt of the intercepted signal, Open MPI will display a stack trace and abort. Open MPI will *not* replace signals if handlers are already installed by the time MPI_INIT is invoked. Optionally append \":complain\" to any signal number in the comma-delimited list to make Open MPI complain if it detects another signal handler (and therefore does not insert its own).",
false, false, string, NULL);
free(string);
}
#if OPAL_ENABLE_DEBUG
mca_base_param_reg_int_name("opal", "progress_debug",
"Set to non-zero to debug progress engine features",
false, false, 0, NULL);
{
mca_base_param_reg_int_name("opal", "debug_locks",
"Debug mutex usage within Open MPI. On a "
"non-threaded build, this enables integer counters and "
"warning messages when double-locks are detected.",
false, false, 0, &value);
if (value) opal_mutex_check_locks = true;
mca_base_param_reg_int_name("opal", "debug_threads",
"Debug thread usage within OPAL. Reports out "
"when threads are acquired and released.",
false, false, 0, &value);
if (value) opal_debug_threads = true;
}
#endif
- Split the datatype engine into two parts: an MPI specific part in OMPI and a language agnostic part in OPAL. The convertor is completely moved into OPAL. This offers several benefits as described in RFC http://www.open-mpi.org/community/lists/devel/2009/07/6387.php namely: - Fewer basic types (int* and float* types, boolean and wchar - Fixing naming scheme to ompi-nomenclature. - Usability outside of the ompi-layer. - Due to the fixed nature of simple opal types, their information is completely known at compile time and therefore constified - With fewer datatypes (22), the actual sizes of bit-field types may be reduced from 64 to 32 bits, allowing reorganizing the opal_datatype structure, eliminating holes and keeping data required in convertor (upon send/recv) in one cacheline... This has implications to the convertor-datastructure and other parts of the code. - Several performance tests have been run, the netpipe latency does not change with this patch on Linux/x86-64 on the smoky cluster. - Extensive tests have been done to verify correctness (no new regressions) using: 1. mpi_test_suite on linux/x86-64 using clean ompi-trunk and ompi-ddt: a. running both trunk and ompi-ddt resulted in no differences (except for MPI_SHORT_INT and MPI_TYPE_MIX_LB_UB do now run correctly). b. with --enable-memchecker and running under valgrind (one buglet when run with static found in test-suite, commited) 2. ibm testsuite on linux/x86-64 using clean ompi-trunk and ompi-ddt: all passed (except for the dynamic/ tests failed!! as trunk/MTT) 3. compilation and usage of HDF5 tests on Jaguar using PGI and PathScale compilers. 4. compilation and usage on Scicortex. - Please note, that for the heterogeneous case, (-m32 compiled binaries/ompi), neither ompi-trunk, nor ompi-ddt branch would successfully launch. This commit was SVN r21641.
2009-07-13 08:56:31 +04:00
/* The ddt engine has a few parameters */
Brice Goglin noticed that mpi_paffinity_alone didn't seem to be doing anything for non-MPI apps. Oops! (But before you freak out, gentle reader, note that mpi_paffinity_alone for MPI apps still worked fine) When we made the switchover somewhere in the 1.3 series to have the orted's do processor binding, then stuff like: mpirun --mca mpi_paffinity_alone 1 hostname should have bound hostname to processor 0. But it didn't because of a subtle startup ordering issue: the MCA param registration for opal_paffinity_alone was in the paffinity base (vs. being in opal/runtime/opal_params.c), but it didn't actually get registered until after the global variable opal_paffinity_alone was checked to see if we wanted old-style affinity bindings. Oops. However, for MPI apps, even though the orted didn't do the binding, ompi_mpi_init() would notice that opal_paffinity_alone was set, yet the process didn't seem to be bound. So the MPI process would bind itself (this was done to support the running-without-orteds scenarios). Hence, MPI apps still obeyed mpi_paffinity_alone semantics. But note that the error described above caused the new mpirun switch --report-bindings to not work with mpi_paffinity_alone=1, meaning that the orted would not report the bindings when mpi_paffinity_alone was set to 1 (it ''did'' correctly report bindings if you used --bind-to-core or one of the other binding options). This commit separates out the paffinity base MCA param registration into a small function that can be called at the Right place during the startup sequence. This commit was SVN r22602.
2010-02-11 01:32:00 +03:00
ret = opal_datatype_register_params();
if (OPAL_SUCCESS != ret) {
return ret;
}
/* shmem base also has a few parameters */
ret = opal_shmem_base_register_params();
if (OPAL_SUCCESS != ret) {
return ret;
}
Per RFC, bring in the following changes: * Remove paffinity, maffinity, and carto frameworks -- they've been wholly replaced by hwloc. * Move ompi_mpi_init() affinity-setting/checking code down to ORTE. * Update sm, smcuda, wv, and openib components to no longer use carto. Instead, use hwloc data. There are still optimizations possible in the sm/smcuda BTLs (i.e., making multiple mpools). Also, the old carto-based code found out how many NUMA nodes were ''available'' -- not how many were used ''in this job''. The new hwloc-using code computes the same value -- it was not updated to calculate how many NUMA nodes are used ''by this job.'' * Note that I cannot compile the smcuda and wv BTLs -- I ''think'' they're right, but they need to be verified by their owners. * The openib component now does a bunch of stuff to figure out where "near" OpenFabrics devices are. '''THIS IS A CHANGE IN DEFAULT BEHAVIOR!!''' and still needs to be verified by OpenFabrics vendors (I do not have a NUMA machine with an OpenFabrics device that is a non-uniform distance from multiple different NUMA nodes). * Completely rewrite the OMPI_Affinity_str() routine from the "affinity" mpiext extension. This extension now understands hyperthreads; the output format of it has changed a bit to reflect this new information. * Bunches of minor changes around the code base to update names/types from maffinity/paffinity-based names to hwloc-based names. * Add some helper functions into the hwloc base, mainly having to do with the fact that we have the hwloc data reporting ''all'' topology information, but sometimes you really only want the (online | available) data. This commit was SVN r26391.
2012-05-07 18:52:54 +04:00
return OPAL_SUCCESS;
}