2007-04-23 22:28:20 +04:00
|
|
|
/*
|
2007-07-12 23:53:18 +04:00
|
|
|
* Copyright (c) 2004-2007 The Trustees of Indiana University and Indiana
|
2007-04-23 22:28:20 +04:00
|
|
|
* University Research and Technology
|
|
|
|
* Corporation. All rights reserved.
|
2008-02-28 08:32:23 +03:00
|
|
|
* Copyright (c) 2004-2008 The University of Tennessee and The University
|
2007-04-23 22:28:20 +04:00
|
|
|
* 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.
|
2009-01-11 05:30:00 +03:00
|
|
|
* Copyright (c) 2007 Cisco Systems, Inc. All rights reserved.
|
2007-07-12 23:53:18 +04:00
|
|
|
* Copyright (c) 2007 Los Alamos National Security, LLC. All rights
|
|
|
|
* reserved.
|
2007-04-23 22:28:20 +04:00
|
|
|
* $COPYRIGHT$
|
|
|
|
*
|
|
|
|
* Additional copyrights may follow
|
|
|
|
*
|
|
|
|
* $HEADER$
|
|
|
|
*/
|
|
|
|
|
|
|
|
#include "orte_config.h"
|
2008-02-28 04:57:57 +03:00
|
|
|
#include "orte/constants.h"
|
2007-04-23 22:28:20 +04:00
|
|
|
|
|
|
|
#include <stdio.h>
|
|
|
|
#include <ctype.h>
|
|
|
|
#ifdef HAVE_UNISTD_H
|
|
|
|
#include <unistd.h>
|
|
|
|
#endif
|
|
|
|
#ifdef HAVE_NETDB_H
|
|
|
|
#include <netdb.h>
|
|
|
|
#endif
|
|
|
|
#ifdef HAVE_SYS_PARAM_H
|
|
|
|
#include <sys/param.h>
|
|
|
|
#endif
|
|
|
|
#include <fcntl.h>
|
|
|
|
#include <errno.h>
|
|
|
|
#include <signal.h>
|
2009-01-08 17:27:52 +03:00
|
|
|
#ifdef HAVE_SYS_TIME_H
|
|
|
|
#include <sys/time.h>
|
|
|
|
#endif /* HAVE_SYS_TIME_H */
|
2007-04-23 22:28:20 +04:00
|
|
|
|
|
|
|
|
|
|
|
#include "opal/event/event.h"
|
|
|
|
#include "opal/mca/base/base.h"
|
|
|
|
#include "opal/threads/mutex.h"
|
|
|
|
#include "opal/threads/condition.h"
|
|
|
|
#include "opal/util/bit_ops.h"
|
2007-07-12 23:53:18 +04:00
|
|
|
#include "opal/util/cmd_line.h"
|
|
|
|
#include "opal/util/opal_environ.h"
|
|
|
|
#include "opal/util/os_path.h"
|
|
|
|
#include "opal/util/printf.h"
|
2007-04-23 22:28:20 +04:00
|
|
|
#include "opal/util/trace.h"
|
2007-07-12 23:53:18 +04:00
|
|
|
#include "opal/util/argv.h"
|
|
|
|
#include "opal/runtime/opal.h"
|
|
|
|
#include "opal/mca/base/mca_base_param.h"
|
2008-02-28 04:57:57 +03:00
|
|
|
#include "opal/util/daemon_init.h"
|
|
|
|
#include "opal/dss/dss.h"
|
2007-07-12 23:53:18 +04:00
|
|
|
|
2008-06-09 18:53:58 +04:00
|
|
|
#include "orte/util/show_help.h"
|
2007-04-23 22:28:20 +04:00
|
|
|
#include "orte/util/proc_info.h"
|
2007-07-12 23:53:18 +04:00
|
|
|
#include "orte/util/session_dir.h"
|
2008-02-28 04:57:57 +03:00
|
|
|
#include "orte/util/name_fns.h"
|
Afraid this has a couple of things mixed into the commit. Couldn't be helped - had missed one commit prior to running out the door on vacation.
Fix race conditions in abnormal terminations. We had done a first-cut at this in a prior commit. However, the window remained partially open due to the fact that the HNP has multiple paths leading to orte_finalize. Most of our frameworks don't care if they are finalized more than once, but one of them does, which meant we segfaulted if orte_finalize got called more than once. Besides, we really shouldn't be doing that anyway.
So we now introduce a set of atomic locks that prevent us from multiply calling abort, attempting to call orte_finalize, etc. My initial tests indicate this is working cleanly, but since it is a race condition issue, more testing will have to be done before we know for sure that this problem has been licked.
Also, some updates relevant to the tool comm library snuck in here. Since those also touched the orted code (as did the prior changes), I didn't want to attempt to separate them out - besides, they are coming in soon anyway. More on them later as that functionality approaches completion.
This commit was SVN r17843.
2008-03-17 20:58:59 +03:00
|
|
|
#include "orte/runtime/orte_locks.h"
|
2007-04-23 22:28:20 +04:00
|
|
|
|
|
|
|
#include "orte/mca/errmgr/errmgr.h"
|
|
|
|
#include "orte/mca/rml/rml.h"
|
2007-07-20 05:34:02 +04:00
|
|
|
#include "orte/mca/rml/base/rml_contact.h"
|
2007-07-12 23:53:18 +04:00
|
|
|
#include "orte/mca/odls/odls.h"
|
2008-02-28 04:57:57 +03:00
|
|
|
#include "orte/mca/plm/plm.h"
|
|
|
|
#include "orte/mca/ras/ras.h"
|
2008-04-14 22:26:08 +04:00
|
|
|
#include "orte/mca/routed/routed.h"
|
2007-07-12 23:53:18 +04:00
|
|
|
|
2008-02-28 04:57:57 +03:00
|
|
|
/* need access to the create_jobid fn used by plm components
|
|
|
|
* so we can set singleton name, if necessary
|
|
|
|
*/
|
|
|
|
#include "orte/mca/plm/base/plm_private.h"
|
2007-07-12 23:53:18 +04:00
|
|
|
|
|
|
|
#include "orte/runtime/runtime.h"
|
2008-02-28 04:57:57 +03:00
|
|
|
#include "orte/runtime/orte_globals.h"
|
|
|
|
#include "orte/runtime/orte_wait.h"
|
2007-04-23 22:28:20 +04:00
|
|
|
|
2007-07-12 23:53:18 +04:00
|
|
|
#include "orte/orted/orted.h"
|
2007-04-23 22:28:20 +04:00
|
|
|
|
2007-07-12 23:53:18 +04:00
|
|
|
/*
|
|
|
|
* Globals
|
|
|
|
*/
|
|
|
|
|
2008-02-28 04:57:57 +03:00
|
|
|
static opal_event_t term_handler;
|
|
|
|
static opal_event_t int_handler;
|
|
|
|
static opal_event_t pipe_handler;
|
2007-09-12 18:32:31 +04:00
|
|
|
#ifndef __WINDOWS__
|
2008-02-28 04:57:57 +03:00
|
|
|
static opal_event_t sigusr1_handler;
|
|
|
|
static opal_event_t sigusr2_handler;
|
2007-09-12 18:32:31 +04:00
|
|
|
#endif /* __WINDOWS__ */
|
2008-02-28 04:57:57 +03:00
|
|
|
char *log_path = NULL;
|
|
|
|
static opal_event_t *orted_exit_event;
|
2007-07-12 23:53:18 +04:00
|
|
|
|
|
|
|
static void shutdown_callback(int fd, short flags, void *arg);
|
2008-08-05 19:09:29 +04:00
|
|
|
static void shutdown_signal(int fd, short flags, void *arg);
|
2008-02-28 04:57:57 +03:00
|
|
|
static void signal_callback(int fd, short event, void *arg);
|
2007-07-12 23:53:18 +04:00
|
|
|
|
|
|
|
static struct {
|
This commit represents a bunch of work on a Mercurial side branch. As
such, the commit message back to the master SVN repository is fairly
long.
= ORTE Job-Level Output Messages =
Add two new interfaces that should be used for all new code throughout
the ORTE and OMPI layers (we already make the search-and-replace on
the existing ORTE / OMPI layers):
* orte_output(): (and corresponding friends ORTE_OUTPUT,
orte_output_verbose, etc.) This function sends the output directly
to the HNP for processing as part of a job-specific output
channel. It supports all the same outputs as opal_output()
(syslog, file, stdout, stderr), but for stdout/stderr, the output
is sent to the HNP for processing and output. More on this below.
* orte_show_help(): This function is a drop-in-replacement for
opal_show_help(), with two differences in functionality:
1. the rendered text help message output is sent to the HNP for
display (rather than outputting directly into the process' stderr
stream)
1. the HNP detects duplicate help messages and does not display them
(so that you don't see the same error message N times, once from
each of your N MPI processes); instead, it counts "new" instances
of the help message and displays a message every ~5 seconds when
there are new ones ("I got X new copies of the help message...")
opal_show_help and opal_output still exist, but they only output in
the current process. The intent for the new orte_* functions is that
they can apply job-level intelligence to the output. As such, we
recommend that all new ORTE and OMPI code use the new orte_*
functions, not thei opal_* functions.
=== New code ===
For ORTE and OMPI programmers, here's what you need to do differently
in new code:
* Do not include opal/util/show_help.h or opal/util/output.h.
Instead, include orte/util/output.h (this one header file has
declarations for both the orte_output() series of functions and
orte_show_help()).
* Effectively s/opal_output/orte_output/gi throughout your code.
Note that orte_output_open() takes a slightly different argument
list (as a way to pass data to the filtering stream -- see below),
so you if explicitly call opal_output_open(), you'll need to
slightly adapt to the new signature of orte_output_open().
* Literally s/opal_show_help/orte_show_help/. The function signature
is identical.
=== Notes ===
* orte_output'ing to stream 0 will do similar to what
opal_output'ing did, so leaving a hard-coded "0" as the first
argument is safe.
* For systems that do not use ORTE's RML or the HNP, the effect of
orte_output_* and orte_show_help will be identical to their opal
counterparts (the additional information passed to
orte_output_open() will be lost!). Indeed, the orte_* functions
simply become trivial wrappers to their opal_* counterparts. Note
that we have not tested this; the code is simple but it is quite
possible that we mucked something up.
= Filter Framework =
Messages sent view the new orte_* functions described above and
messages output via the IOF on the HNP will now optionally be passed
through a new "filter" framework before being output to
stdout/stderr. The "filter" OPAL MCA framework is intended to allow
preprocessing to messages before they are sent to their final
destinations. The first component that was written in the filter
framework was to create an XML stream, segregating all the messages
into different XML tags, etc. This will allow 3rd party tools to read
the stdout/stderr from the HNP and be able to know exactly what each
text message is (e.g., a help message, another OMPI infrastructure
message, stdout from the user process, stderr from the user process,
etc.).
Filtering is not active by default. Filter components must be
specifically requested, such as:
{{{
$ mpirun --mca filter xml ...
}}}
There can only be one filter component active.
= New MCA Parameters =
The new functionality described above introduces two new MCA
parameters:
* '''orte_base_help_aggregate''': Defaults to 1 (true), meaning that
help messages will be aggregated, as described above. If set to 0,
all help messages will be displayed, even if they are duplicates
(i.e., the original behavior).
* '''orte_base_show_output_recursions''': An MCA parameter to help
debug one of the known issues, described below. It is likely that
this MCA parameter will disappear before v1.3 final.
= Known Issues =
* The XML filter component is not complete. The current output from
this component is preliminary and not real XML. A bit more work
needs to be done to configure.m4 search for an appropriate XML
library/link it in/use it at run time.
* There are possible recursion loops in the orte_output() and
orte_show_help() functions -- e.g., if RML send calls orte_output()
or orte_show_help(). We have some ideas how to fix these, but
figured that it was ok to commit before feature freeze with known
issues. The code currently contains sub-optimal workarounds so
that this will not be a problem, but it would be good to actually
solve the problem rather than have hackish workarounds before v1.3 final.
This commit was SVN r18434.
2008-05-14 00:00:55 +04:00
|
|
|
bool debug;
|
2007-07-12 23:53:18 +04:00
|
|
|
bool help;
|
|
|
|
bool set_sid;
|
2008-02-28 04:57:57 +03:00
|
|
|
bool hnp;
|
|
|
|
bool daemonize;
|
2007-07-12 23:53:18 +04:00
|
|
|
char* name;
|
|
|
|
char* vpid_start;
|
|
|
|
char* num_procs;
|
|
|
|
int uri_pipe;
|
|
|
|
int singleton_died_pipe;
|
2008-05-29 17:38:27 +04:00
|
|
|
int fail;
|
2008-06-03 01:46:34 +04:00
|
|
|
int fail_delay;
|
|
|
|
bool abort;
|
|
|
|
int heartbeat;
|
2007-07-12 23:53:18 +04:00
|
|
|
} orted_globals;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* define the orted context table for obtaining parameters
|
|
|
|
*/
|
|
|
|
opal_cmd_line_init_t orte_cmd_line_opts[] = {
|
|
|
|
/* Various "obvious" options */
|
|
|
|
{ NULL, NULL, NULL, 'h', NULL, "help", 0,
|
|
|
|
&orted_globals.help, OPAL_CMD_LINE_TYPE_BOOL,
|
|
|
|
"This help message" },
|
|
|
|
|
2008-07-02 05:46:58 +04:00
|
|
|
{ NULL, NULL, NULL, 's', NULL, "spin", 0,
|
|
|
|
&orted_spin_flag, OPAL_CMD_LINE_TYPE_BOOL,
|
2007-07-12 23:53:18 +04:00
|
|
|
"Have the orted spin until we can connect a debugger to it" },
|
|
|
|
|
2008-05-29 17:38:27 +04:00
|
|
|
{ NULL, NULL, NULL, '\0', NULL, "debug-failure", 1,
|
2008-06-03 01:46:34 +04:00
|
|
|
&orted_globals.fail, OPAL_CMD_LINE_TYPE_INT,
|
2008-05-29 17:38:27 +04:00
|
|
|
"Have the specified orted fail after init for debugging purposes" },
|
|
|
|
|
2008-06-03 01:46:34 +04:00
|
|
|
{ NULL, NULL, NULL, '\0', NULL, "debug-failure-delay", 1,
|
|
|
|
&orted_globals.fail_delay, OPAL_CMD_LINE_TYPE_INT,
|
|
|
|
"Have the orted specified for failure delay for the provided number of seconds before failing" },
|
|
|
|
|
|
|
|
{ NULL, NULL, NULL, '\0', NULL, "heartbeat", 1,
|
|
|
|
&orted_globals.heartbeat, OPAL_CMD_LINE_TYPE_INT,
|
|
|
|
"Seconds between orted heartbeat messages to be sent to HNP (default: 0 => no heartbeat)" },
|
|
|
|
|
2007-07-12 23:53:18 +04:00
|
|
|
{ "orte", "debug", NULL, 'd', NULL, "debug", 0,
|
2008-06-03 01:46:34 +04:00
|
|
|
NULL, OPAL_CMD_LINE_TYPE_BOOL,
|
|
|
|
"Debug the OpenRTE" },
|
2007-07-12 23:53:18 +04:00
|
|
|
|
2008-02-28 04:57:57 +03:00
|
|
|
{ "orte", "daemonize", NULL, '\0', NULL, "daemonize", 0,
|
|
|
|
&orted_globals.daemonize, OPAL_CMD_LINE_TYPE_BOOL,
|
|
|
|
"Daemonize the orted into the background" },
|
2007-07-12 23:53:18 +04:00
|
|
|
|
|
|
|
{ "orte", "debug", "daemons", '\0', NULL, "debug-daemons", 0,
|
This commit represents a bunch of work on a Mercurial side branch. As
such, the commit message back to the master SVN repository is fairly
long.
= ORTE Job-Level Output Messages =
Add two new interfaces that should be used for all new code throughout
the ORTE and OMPI layers (we already make the search-and-replace on
the existing ORTE / OMPI layers):
* orte_output(): (and corresponding friends ORTE_OUTPUT,
orte_output_verbose, etc.) This function sends the output directly
to the HNP for processing as part of a job-specific output
channel. It supports all the same outputs as opal_output()
(syslog, file, stdout, stderr), but for stdout/stderr, the output
is sent to the HNP for processing and output. More on this below.
* orte_show_help(): This function is a drop-in-replacement for
opal_show_help(), with two differences in functionality:
1. the rendered text help message output is sent to the HNP for
display (rather than outputting directly into the process' stderr
stream)
1. the HNP detects duplicate help messages and does not display them
(so that you don't see the same error message N times, once from
each of your N MPI processes); instead, it counts "new" instances
of the help message and displays a message every ~5 seconds when
there are new ones ("I got X new copies of the help message...")
opal_show_help and opal_output still exist, but they only output in
the current process. The intent for the new orte_* functions is that
they can apply job-level intelligence to the output. As such, we
recommend that all new ORTE and OMPI code use the new orte_*
functions, not thei opal_* functions.
=== New code ===
For ORTE and OMPI programmers, here's what you need to do differently
in new code:
* Do not include opal/util/show_help.h or opal/util/output.h.
Instead, include orte/util/output.h (this one header file has
declarations for both the orte_output() series of functions and
orte_show_help()).
* Effectively s/opal_output/orte_output/gi throughout your code.
Note that orte_output_open() takes a slightly different argument
list (as a way to pass data to the filtering stream -- see below),
so you if explicitly call opal_output_open(), you'll need to
slightly adapt to the new signature of orte_output_open().
* Literally s/opal_show_help/orte_show_help/. The function signature
is identical.
=== Notes ===
* orte_output'ing to stream 0 will do similar to what
opal_output'ing did, so leaving a hard-coded "0" as the first
argument is safe.
* For systems that do not use ORTE's RML or the HNP, the effect of
orte_output_* and orte_show_help will be identical to their opal
counterparts (the additional information passed to
orte_output_open() will be lost!). Indeed, the orte_* functions
simply become trivial wrappers to their opal_* counterparts. Note
that we have not tested this; the code is simple but it is quite
possible that we mucked something up.
= Filter Framework =
Messages sent view the new orte_* functions described above and
messages output via the IOF on the HNP will now optionally be passed
through a new "filter" framework before being output to
stdout/stderr. The "filter" OPAL MCA framework is intended to allow
preprocessing to messages before they are sent to their final
destinations. The first component that was written in the filter
framework was to create an XML stream, segregating all the messages
into different XML tags, etc. This will allow 3rd party tools to read
the stdout/stderr from the HNP and be able to know exactly what each
text message is (e.g., a help message, another OMPI infrastructure
message, stdout from the user process, stderr from the user process,
etc.).
Filtering is not active by default. Filter components must be
specifically requested, such as:
{{{
$ mpirun --mca filter xml ...
}}}
There can only be one filter component active.
= New MCA Parameters =
The new functionality described above introduces two new MCA
parameters:
* '''orte_base_help_aggregate''': Defaults to 1 (true), meaning that
help messages will be aggregated, as described above. If set to 0,
all help messages will be displayed, even if they are duplicates
(i.e., the original behavior).
* '''orte_base_show_output_recursions''': An MCA parameter to help
debug one of the known issues, described below. It is likely that
this MCA parameter will disappear before v1.3 final.
= Known Issues =
* The XML filter component is not complete. The current output from
this component is preliminary and not real XML. A bit more work
needs to be done to configure.m4 search for an appropriate XML
library/link it in/use it at run time.
* There are possible recursion loops in the orte_output() and
orte_show_help() functions -- e.g., if RML send calls orte_output()
or orte_show_help(). We have some ideas how to fix these, but
figured that it was ok to commit before feature freeze with known
issues. The code currently contains sub-optimal workarounds so
that this will not be a problem, but it would be good to actually
solve the problem rather than have hackish workarounds before v1.3 final.
This commit was SVN r18434.
2008-05-14 00:00:55 +04:00
|
|
|
&orted_globals.debug, OPAL_CMD_LINE_TYPE_BOOL,
|
2007-07-12 23:53:18 +04:00
|
|
|
"Enable debugging of OpenRTE daemons" },
|
|
|
|
|
|
|
|
{ "orte", "debug", "daemons_file", '\0', NULL, "debug-daemons-file", 0,
|
|
|
|
NULL, OPAL_CMD_LINE_TYPE_BOOL,
|
|
|
|
"Enable debugging of OpenRTE daemons, storing output in files" },
|
|
|
|
|
2008-02-28 04:57:57 +03:00
|
|
|
{ NULL, NULL, NULL, '\0', NULL, "hnp", 0,
|
|
|
|
&orted_globals.hnp, OPAL_CMD_LINE_TYPE_BOOL,
|
|
|
|
"Direct the orted to act as the HNP"},
|
|
|
|
|
|
|
|
{ "orte", "hnp", "uri", '\0', NULL, "hnp-uri", 1,
|
|
|
|
NULL, OPAL_CMD_LINE_TYPE_STRING,
|
|
|
|
"URI for the HNP"},
|
|
|
|
|
2007-07-12 23:53:18 +04:00
|
|
|
{ NULL, NULL, NULL, '\0', NULL, "set-sid", 0,
|
|
|
|
&orted_globals.set_sid, OPAL_CMD_LINE_TYPE_BOOL,
|
|
|
|
"Direct the orted to separate from the current session"},
|
|
|
|
|
|
|
|
{ "tmpdir", "base", NULL, '\0', NULL, "tmpdir", 1,
|
|
|
|
NULL, OPAL_CMD_LINE_TYPE_STRING,
|
|
|
|
"Set the root for the session directory tree" },
|
|
|
|
|
|
|
|
{ NULL, NULL, NULL, '\0', NULL, "report-uri", 1,
|
|
|
|
&orted_globals.uri_pipe, OPAL_CMD_LINE_TYPE_INT,
|
|
|
|
"Report this process' uri on indicated pipe"},
|
|
|
|
|
|
|
|
{ NULL, NULL, NULL, '\0', NULL, "singleton-died-pipe", 1,
|
|
|
|
&orted_globals.singleton_died_pipe, OPAL_CMD_LINE_TYPE_INT,
|
|
|
|
"Watch on indicated pipe for singleton termination"},
|
|
|
|
|
2009-02-03 23:06:05 +03:00
|
|
|
{ "orte", "output", "filename", '\0', "output-filename", "output-filename", 1,
|
|
|
|
NULL, OPAL_CMD_LINE_TYPE_STRING,
|
|
|
|
"Redirect output from application processes into filename.rank" },
|
|
|
|
|
|
|
|
{ "orte", "xterm", NULL, '\0', "xterm", "xterm", 1,
|
|
|
|
NULL, OPAL_CMD_LINE_TYPE_STRING,
|
|
|
|
"Create a new xterm window and display output from the specified ranks there" },
|
|
|
|
|
2007-07-12 23:53:18 +04:00
|
|
|
/* End of list */
|
|
|
|
{ NULL, NULL, NULL, '\0', NULL, NULL, 0,
|
|
|
|
NULL, OPAL_CMD_LINE_TYPE_NULL, NULL }
|
|
|
|
};
|
|
|
|
|
|
|
|
int orte_daemon(int argc, char *argv[])
|
|
|
|
{
|
|
|
|
int ret = 0;
|
|
|
|
int fd;
|
|
|
|
opal_cmd_line_t *cmd_line = NULL;
|
|
|
|
char log_file[PATH_MAX];
|
|
|
|
char *jobidstring;
|
2008-02-28 04:57:57 +03:00
|
|
|
char *rml_uri;
|
2007-07-12 23:53:18 +04:00
|
|
|
int i;
|
2008-02-28 04:57:57 +03:00
|
|
|
opal_buffer_t *buffer;
|
2007-07-23 19:00:39 +04:00
|
|
|
char hostname[100];
|
2008-04-23 04:17:12 +04:00
|
|
|
char *tmp_env_var = NULL;
|
2009-01-08 17:27:52 +03:00
|
|
|
struct timeval starttime, setuptime;
|
|
|
|
|
|
|
|
/* get our time for first executable */
|
|
|
|
gettimeofday(&starttime, NULL);
|
|
|
|
|
2007-07-12 23:53:18 +04:00
|
|
|
/* initialize the globals */
|
|
|
|
memset(&orted_globals, 0, sizeof(orted_globals));
|
|
|
|
/* initialize the singleton died pipe to an illegal value so we can detect it was set */
|
|
|
|
orted_globals.singleton_died_pipe = -1;
|
2008-05-29 17:38:27 +04:00
|
|
|
/* init the failure orted vpid to an invalid value */
|
|
|
|
orted_globals.fail = ORTE_VPID_INVALID;
|
|
|
|
|
2007-07-12 23:53:18 +04:00
|
|
|
/* setup to check common command line options that just report and die */
|
|
|
|
cmd_line = OBJ_NEW(opal_cmd_line_t);
|
|
|
|
opal_cmd_line_create(cmd_line, orte_cmd_line_opts);
|
|
|
|
mca_base_cmd_line_setup(cmd_line);
|
|
|
|
if (ORTE_SUCCESS != (ret = opal_cmd_line_parse(cmd_line, false,
|
|
|
|
argc, argv))) {
|
|
|
|
char *args = NULL;
|
|
|
|
args = opal_cmd_line_get_usage_msg(cmd_line);
|
This commit represents a bunch of work on a Mercurial side branch. As
such, the commit message back to the master SVN repository is fairly
long.
= ORTE Job-Level Output Messages =
Add two new interfaces that should be used for all new code throughout
the ORTE and OMPI layers (we already make the search-and-replace on
the existing ORTE / OMPI layers):
* orte_output(): (and corresponding friends ORTE_OUTPUT,
orte_output_verbose, etc.) This function sends the output directly
to the HNP for processing as part of a job-specific output
channel. It supports all the same outputs as opal_output()
(syslog, file, stdout, stderr), but for stdout/stderr, the output
is sent to the HNP for processing and output. More on this below.
* orte_show_help(): This function is a drop-in-replacement for
opal_show_help(), with two differences in functionality:
1. the rendered text help message output is sent to the HNP for
display (rather than outputting directly into the process' stderr
stream)
1. the HNP detects duplicate help messages and does not display them
(so that you don't see the same error message N times, once from
each of your N MPI processes); instead, it counts "new" instances
of the help message and displays a message every ~5 seconds when
there are new ones ("I got X new copies of the help message...")
opal_show_help and opal_output still exist, but they only output in
the current process. The intent for the new orte_* functions is that
they can apply job-level intelligence to the output. As such, we
recommend that all new ORTE and OMPI code use the new orte_*
functions, not thei opal_* functions.
=== New code ===
For ORTE and OMPI programmers, here's what you need to do differently
in new code:
* Do not include opal/util/show_help.h or opal/util/output.h.
Instead, include orte/util/output.h (this one header file has
declarations for both the orte_output() series of functions and
orte_show_help()).
* Effectively s/opal_output/orte_output/gi throughout your code.
Note that orte_output_open() takes a slightly different argument
list (as a way to pass data to the filtering stream -- see below),
so you if explicitly call opal_output_open(), you'll need to
slightly adapt to the new signature of orte_output_open().
* Literally s/opal_show_help/orte_show_help/. The function signature
is identical.
=== Notes ===
* orte_output'ing to stream 0 will do similar to what
opal_output'ing did, so leaving a hard-coded "0" as the first
argument is safe.
* For systems that do not use ORTE's RML or the HNP, the effect of
orte_output_* and orte_show_help will be identical to their opal
counterparts (the additional information passed to
orte_output_open() will be lost!). Indeed, the orte_* functions
simply become trivial wrappers to their opal_* counterparts. Note
that we have not tested this; the code is simple but it is quite
possible that we mucked something up.
= Filter Framework =
Messages sent view the new orte_* functions described above and
messages output via the IOF on the HNP will now optionally be passed
through a new "filter" framework before being output to
stdout/stderr. The "filter" OPAL MCA framework is intended to allow
preprocessing to messages before they are sent to their final
destinations. The first component that was written in the filter
framework was to create an XML stream, segregating all the messages
into different XML tags, etc. This will allow 3rd party tools to read
the stdout/stderr from the HNP and be able to know exactly what each
text message is (e.g., a help message, another OMPI infrastructure
message, stdout from the user process, stderr from the user process,
etc.).
Filtering is not active by default. Filter components must be
specifically requested, such as:
{{{
$ mpirun --mca filter xml ...
}}}
There can only be one filter component active.
= New MCA Parameters =
The new functionality described above introduces two new MCA
parameters:
* '''orte_base_help_aggregate''': Defaults to 1 (true), meaning that
help messages will be aggregated, as described above. If set to 0,
all help messages will be displayed, even if they are duplicates
(i.e., the original behavior).
* '''orte_base_show_output_recursions''': An MCA parameter to help
debug one of the known issues, described below. It is likely that
this MCA parameter will disappear before v1.3 final.
= Known Issues =
* The XML filter component is not complete. The current output from
this component is preliminary and not real XML. A bit more work
needs to be done to configure.m4 search for an appropriate XML
library/link it in/use it at run time.
* There are possible recursion loops in the orte_output() and
orte_show_help() functions -- e.g., if RML send calls orte_output()
or orte_show_help(). We have some ideas how to fix these, but
figured that it was ok to commit before feature freeze with known
issues. The code currently contains sub-optimal workarounds so
that this will not be a problem, but it would be good to actually
solve the problem rather than have hackish workarounds before v1.3 final.
This commit was SVN r18434.
2008-05-14 00:00:55 +04:00
|
|
|
orte_show_help("help-orted.txt", "orted:usage", false,
|
2007-07-12 23:53:18 +04:00
|
|
|
argv[0], args);
|
|
|
|
free(args);
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Since this process can now handle MCA/GMCA parameters, make sure to
|
|
|
|
* process them.
|
|
|
|
*/
|
|
|
|
mca_base_cmd_line_process_args(cmd_line, &environ, &environ);
|
|
|
|
|
2008-12-10 02:49:02 +03:00
|
|
|
/* make sure that opal_profile is -not- set as we do not care
|
|
|
|
* what frameworks are opened by the daemons
|
|
|
|
*/
|
|
|
|
if (NULL != getenv("OMPI_MCA_opal_profile")) {
|
|
|
|
putenv("OMPI_MCA_opal_profile=0");
|
|
|
|
}
|
|
|
|
|
2007-07-13 22:15:36 +04:00
|
|
|
/* Ensure that enough of OPAL is setup for us to be able to run */
|
2007-07-13 23:08:05 +04:00
|
|
|
/*
|
|
|
|
* NOTE: (JJH)
|
|
|
|
* We need to allow 'mca_base_cmd_line_process_args()' to process command
|
|
|
|
* line arguments *before* calling opal_init_util() since the command
|
|
|
|
* line could contain MCA parameters that affect the way opal_init_util()
|
|
|
|
* functions. AMCA parameters are one such option normally received on the
|
|
|
|
* command line that affect the way opal_init_util() behaves.
|
|
|
|
* It is "safe" to call mca_base_cmd_line_process_args() before
|
|
|
|
* opal_init_util() since mca_base_cmd_line_process_args() does *not*
|
|
|
|
* depend upon opal_init_util() functionality.
|
|
|
|
*/
|
2007-07-13 22:15:36 +04:00
|
|
|
if (OPAL_SUCCESS != opal_init_util()) {
|
|
|
|
fprintf(stderr, "OPAL failed to initialize -- orted aborting\n");
|
|
|
|
exit(1);
|
|
|
|
}
|
|
|
|
|
2008-08-06 15:31:06 +04:00
|
|
|
/* setup the exit triggers */
|
|
|
|
OBJ_CONSTRUCT(&orte_exit, orte_trigger_event_t);
|
|
|
|
|
2008-07-09 02:36:39 +04:00
|
|
|
/* save the environment for launch purposes. This MUST be
|
|
|
|
* done so that we can pass it to any local procs we
|
|
|
|
* spawn - otherwise, those local procs won't see any
|
|
|
|
* non-MCA envars that were set in the enviro when the
|
|
|
|
* orted was executed - e.g., by .csh
|
|
|
|
*/
|
2008-02-28 04:57:57 +03:00
|
|
|
orte_launch_environ = opal_argv_copy(environ);
|
|
|
|
|
2007-07-12 23:53:18 +04:00
|
|
|
|
2007-07-23 19:00:39 +04:00
|
|
|
/* if orte_daemon_debug is set, let someone know we are alive right
|
|
|
|
* away just in case we have a problem along the way
|
|
|
|
*/
|
This commit represents a bunch of work on a Mercurial side branch. As
such, the commit message back to the master SVN repository is fairly
long.
= ORTE Job-Level Output Messages =
Add two new interfaces that should be used for all new code throughout
the ORTE and OMPI layers (we already make the search-and-replace on
the existing ORTE / OMPI layers):
* orte_output(): (and corresponding friends ORTE_OUTPUT,
orte_output_verbose, etc.) This function sends the output directly
to the HNP for processing as part of a job-specific output
channel. It supports all the same outputs as opal_output()
(syslog, file, stdout, stderr), but for stdout/stderr, the output
is sent to the HNP for processing and output. More on this below.
* orte_show_help(): This function is a drop-in-replacement for
opal_show_help(), with two differences in functionality:
1. the rendered text help message output is sent to the HNP for
display (rather than outputting directly into the process' stderr
stream)
1. the HNP detects duplicate help messages and does not display them
(so that you don't see the same error message N times, once from
each of your N MPI processes); instead, it counts "new" instances
of the help message and displays a message every ~5 seconds when
there are new ones ("I got X new copies of the help message...")
opal_show_help and opal_output still exist, but they only output in
the current process. The intent for the new orte_* functions is that
they can apply job-level intelligence to the output. As such, we
recommend that all new ORTE and OMPI code use the new orte_*
functions, not thei opal_* functions.
=== New code ===
For ORTE and OMPI programmers, here's what you need to do differently
in new code:
* Do not include opal/util/show_help.h or opal/util/output.h.
Instead, include orte/util/output.h (this one header file has
declarations for both the orte_output() series of functions and
orte_show_help()).
* Effectively s/opal_output/orte_output/gi throughout your code.
Note that orte_output_open() takes a slightly different argument
list (as a way to pass data to the filtering stream -- see below),
so you if explicitly call opal_output_open(), you'll need to
slightly adapt to the new signature of orte_output_open().
* Literally s/opal_show_help/orte_show_help/. The function signature
is identical.
=== Notes ===
* orte_output'ing to stream 0 will do similar to what
opal_output'ing did, so leaving a hard-coded "0" as the first
argument is safe.
* For systems that do not use ORTE's RML or the HNP, the effect of
orte_output_* and orte_show_help will be identical to their opal
counterparts (the additional information passed to
orte_output_open() will be lost!). Indeed, the orte_* functions
simply become trivial wrappers to their opal_* counterparts. Note
that we have not tested this; the code is simple but it is quite
possible that we mucked something up.
= Filter Framework =
Messages sent view the new orte_* functions described above and
messages output via the IOF on the HNP will now optionally be passed
through a new "filter" framework before being output to
stdout/stderr. The "filter" OPAL MCA framework is intended to allow
preprocessing to messages before they are sent to their final
destinations. The first component that was written in the filter
framework was to create an XML stream, segregating all the messages
into different XML tags, etc. This will allow 3rd party tools to read
the stdout/stderr from the HNP and be able to know exactly what each
text message is (e.g., a help message, another OMPI infrastructure
message, stdout from the user process, stderr from the user process,
etc.).
Filtering is not active by default. Filter components must be
specifically requested, such as:
{{{
$ mpirun --mca filter xml ...
}}}
There can only be one filter component active.
= New MCA Parameters =
The new functionality described above introduces two new MCA
parameters:
* '''orte_base_help_aggregate''': Defaults to 1 (true), meaning that
help messages will be aggregated, as described above. If set to 0,
all help messages will be displayed, even if they are duplicates
(i.e., the original behavior).
* '''orte_base_show_output_recursions''': An MCA parameter to help
debug one of the known issues, described below. It is likely that
this MCA parameter will disappear before v1.3 final.
= Known Issues =
* The XML filter component is not complete. The current output from
this component is preliminary and not real XML. A bit more work
needs to be done to configure.m4 search for an appropriate XML
library/link it in/use it at run time.
* There are possible recursion loops in the orte_output() and
orte_show_help() functions -- e.g., if RML send calls orte_output()
or orte_show_help(). We have some ideas how to fix these, but
figured that it was ok to commit before feature freeze with known
issues. The code currently contains sub-optimal workarounds so
that this will not be a problem, but it would be good to actually
solve the problem rather than have hackish workarounds before v1.3 final.
This commit was SVN r18434.
2008-05-14 00:00:55 +04:00
|
|
|
if (orted_globals.debug) {
|
2007-07-23 19:00:39 +04:00
|
|
|
gethostname(hostname, 100);
|
|
|
|
fprintf(stderr, "Daemon was launched on %s - beginning to initialize\n", hostname);
|
|
|
|
}
|
|
|
|
|
2007-07-12 23:53:18 +04:00
|
|
|
/* check for help request */
|
|
|
|
if (orted_globals.help) {
|
|
|
|
char *args = NULL;
|
|
|
|
args = opal_cmd_line_get_usage_msg(cmd_line);
|
This commit represents a bunch of work on a Mercurial side branch. As
such, the commit message back to the master SVN repository is fairly
long.
= ORTE Job-Level Output Messages =
Add two new interfaces that should be used for all new code throughout
the ORTE and OMPI layers (we already make the search-and-replace on
the existing ORTE / OMPI layers):
* orte_output(): (and corresponding friends ORTE_OUTPUT,
orte_output_verbose, etc.) This function sends the output directly
to the HNP for processing as part of a job-specific output
channel. It supports all the same outputs as opal_output()
(syslog, file, stdout, stderr), but for stdout/stderr, the output
is sent to the HNP for processing and output. More on this below.
* orte_show_help(): This function is a drop-in-replacement for
opal_show_help(), with two differences in functionality:
1. the rendered text help message output is sent to the HNP for
display (rather than outputting directly into the process' stderr
stream)
1. the HNP detects duplicate help messages and does not display them
(so that you don't see the same error message N times, once from
each of your N MPI processes); instead, it counts "new" instances
of the help message and displays a message every ~5 seconds when
there are new ones ("I got X new copies of the help message...")
opal_show_help and opal_output still exist, but they only output in
the current process. The intent for the new orte_* functions is that
they can apply job-level intelligence to the output. As such, we
recommend that all new ORTE and OMPI code use the new orte_*
functions, not thei opal_* functions.
=== New code ===
For ORTE and OMPI programmers, here's what you need to do differently
in new code:
* Do not include opal/util/show_help.h or opal/util/output.h.
Instead, include orte/util/output.h (this one header file has
declarations for both the orte_output() series of functions and
orte_show_help()).
* Effectively s/opal_output/orte_output/gi throughout your code.
Note that orte_output_open() takes a slightly different argument
list (as a way to pass data to the filtering stream -- see below),
so you if explicitly call opal_output_open(), you'll need to
slightly adapt to the new signature of orte_output_open().
* Literally s/opal_show_help/orte_show_help/. The function signature
is identical.
=== Notes ===
* orte_output'ing to stream 0 will do similar to what
opal_output'ing did, so leaving a hard-coded "0" as the first
argument is safe.
* For systems that do not use ORTE's RML or the HNP, the effect of
orte_output_* and orte_show_help will be identical to their opal
counterparts (the additional information passed to
orte_output_open() will be lost!). Indeed, the orte_* functions
simply become trivial wrappers to their opal_* counterparts. Note
that we have not tested this; the code is simple but it is quite
possible that we mucked something up.
= Filter Framework =
Messages sent view the new orte_* functions described above and
messages output via the IOF on the HNP will now optionally be passed
through a new "filter" framework before being output to
stdout/stderr. The "filter" OPAL MCA framework is intended to allow
preprocessing to messages before they are sent to their final
destinations. The first component that was written in the filter
framework was to create an XML stream, segregating all the messages
into different XML tags, etc. This will allow 3rd party tools to read
the stdout/stderr from the HNP and be able to know exactly what each
text message is (e.g., a help message, another OMPI infrastructure
message, stdout from the user process, stderr from the user process,
etc.).
Filtering is not active by default. Filter components must be
specifically requested, such as:
{{{
$ mpirun --mca filter xml ...
}}}
There can only be one filter component active.
= New MCA Parameters =
The new functionality described above introduces two new MCA
parameters:
* '''orte_base_help_aggregate''': Defaults to 1 (true), meaning that
help messages will be aggregated, as described above. If set to 0,
all help messages will be displayed, even if they are duplicates
(i.e., the original behavior).
* '''orte_base_show_output_recursions''': An MCA parameter to help
debug one of the known issues, described below. It is likely that
this MCA parameter will disappear before v1.3 final.
= Known Issues =
* The XML filter component is not complete. The current output from
this component is preliminary and not real XML. A bit more work
needs to be done to configure.m4 search for an appropriate XML
library/link it in/use it at run time.
* There are possible recursion loops in the orte_output() and
orte_show_help() functions -- e.g., if RML send calls orte_output()
or orte_show_help(). We have some ideas how to fix these, but
figured that it was ok to commit before feature freeze with known
issues. The code currently contains sub-optimal workarounds so
that this will not be a problem, but it would be good to actually
solve the problem rather than have hackish workarounds before v1.3 final.
This commit was SVN r18434.
2008-05-14 00:00:55 +04:00
|
|
|
orte_show_help("help-orted.txt", "orted:usage", false,
|
2007-07-12 23:53:18 +04:00
|
|
|
argv[0], args);
|
|
|
|
free(args);
|
|
|
|
return 1;
|
|
|
|
}
|
2008-02-28 04:57:57 +03:00
|
|
|
#if defined(HAVE_SETSID) && !defined(__WINDOWS__)
|
2007-07-12 23:53:18 +04:00
|
|
|
/* see if we were directed to separate from current session */
|
|
|
|
if (orted_globals.set_sid) {
|
|
|
|
setsid();
|
|
|
|
}
|
|
|
|
#endif /* !defined(__WINDOWS__) */
|
|
|
|
/* see if they want us to spin until they can connect a debugger to us */
|
|
|
|
i=0;
|
|
|
|
/*orted_globals.spin = 1;*/
|
|
|
|
while (orted_spin_flag) {
|
|
|
|
i++;
|
|
|
|
if (1000 < i) i=0;
|
|
|
|
}
|
2008-03-23 15:33:04 +03:00
|
|
|
|
2007-07-12 23:53:18 +04:00
|
|
|
/* Okay, now on to serious business! */
|
|
|
|
|
2008-02-28 04:57:57 +03:00
|
|
|
if (orted_globals.hnp) {
|
|
|
|
/* we are to be the hnp, so set that flag */
|
|
|
|
orte_process_info.hnp = true;
|
|
|
|
orte_process_info.daemon = false;
|
|
|
|
} else {
|
|
|
|
/* set ourselves to be just a daemon */
|
|
|
|
orte_process_info.hnp = false;
|
|
|
|
orte_process_info.daemon = true;
|
2007-07-12 23:53:18 +04:00
|
|
|
}
|
|
|
|
|
2007-10-17 17:47:36 +04:00
|
|
|
#if OPAL_ENABLE_FT == 1
|
|
|
|
/* Mark as a tool program */
|
2008-04-23 04:17:12 +04:00
|
|
|
tmp_env_var = mca_base_param_env_var("opal_cr_is_tool");
|
|
|
|
opal_setenv(tmp_env_var,
|
2007-10-17 17:47:36 +04:00
|
|
|
"1",
|
|
|
|
true, &environ);
|
2008-04-23 04:17:12 +04:00
|
|
|
free(tmp_env_var);
|
2007-10-17 17:47:36 +04:00
|
|
|
#endif
|
2008-04-23 04:17:12 +04:00
|
|
|
tmp_env_var = NULL; /* Silence compiler warning */
|
2007-10-17 17:47:36 +04:00
|
|
|
|
2007-07-12 23:53:18 +04:00
|
|
|
/* Set the flag telling OpenRTE that I am NOT a
|
|
|
|
* singleton, but am "infrastructure" - prevents setting
|
|
|
|
* up incorrect infrastructure that only a singleton would
|
|
|
|
* require.
|
|
|
|
*/
|
2008-02-28 04:57:57 +03:00
|
|
|
if (ORTE_SUCCESS != (ret = orte_init(ORTE_NON_TOOL))) {
|
2007-07-12 23:53:18 +04:00
|
|
|
ORTE_ERROR_LOG(ret);
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2008-06-03 01:46:34 +04:00
|
|
|
if ((int)ORTE_VPID_INVALID != orted_globals.fail) {
|
|
|
|
orted_globals.abort=false;
|
|
|
|
/* some vpid was ordered to fail. The value can be positive
|
|
|
|
* or negative, depending upon the desired method for failure,
|
|
|
|
* so need to check both here
|
|
|
|
*/
|
|
|
|
if (0 > orted_globals.fail) {
|
|
|
|
orted_globals.fail = -1*orted_globals.fail;
|
|
|
|
orted_globals.abort = true;
|
|
|
|
}
|
|
|
|
/* are we the specified vpid? */
|
|
|
|
if ((int)ORTE_PROC_MY_NAME->vpid == orted_globals.fail) {
|
|
|
|
/* if the user specified we delay, then setup a timer
|
|
|
|
* and have it kill us
|
|
|
|
*/
|
|
|
|
if (0 < orted_globals.fail_delay) {
|
2008-12-10 23:40:47 +03:00
|
|
|
ORTE_TIMER_EVENT(orted_globals.fail_delay, 0, shutdown_signal);
|
2008-06-03 01:46:34 +04:00
|
|
|
|
|
|
|
} else {
|
|
|
|
opal_output(0, "%s is executing clean %s", ORTE_NAME_PRINT(ORTE_PROC_MY_NAME),
|
|
|
|
orted_globals.abort ? "abort" : "abnormal termination");
|
|
|
|
|
|
|
|
/* do -not- call finalize as this will send a message to the HNP
|
|
|
|
* indicating clean termination! Instead, just forcibly cleanup
|
|
|
|
* the local session_dir tree and exit
|
|
|
|
*/
|
|
|
|
orte_session_dir_cleanup(ORTE_JOBID_WILDCARD);
|
|
|
|
|
|
|
|
/* if we were ordered to abort, do so */
|
|
|
|
if (orted_globals.abort) {
|
|
|
|
abort();
|
|
|
|
}
|
|
|
|
|
|
|
|
/* otherwise, return with non-zero status */
|
|
|
|
return ORTE_ERROR_DEFAULT_EXIT_CODE;
|
|
|
|
}
|
2008-05-29 17:38:27 +04:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
This commit represents a bunch of work on a Mercurial side branch. As
such, the commit message back to the master SVN repository is fairly
long.
= ORTE Job-Level Output Messages =
Add two new interfaces that should be used for all new code throughout
the ORTE and OMPI layers (we already make the search-and-replace on
the existing ORTE / OMPI layers):
* orte_output(): (and corresponding friends ORTE_OUTPUT,
orte_output_verbose, etc.) This function sends the output directly
to the HNP for processing as part of a job-specific output
channel. It supports all the same outputs as opal_output()
(syslog, file, stdout, stderr), but for stdout/stderr, the output
is sent to the HNP for processing and output. More on this below.
* orte_show_help(): This function is a drop-in-replacement for
opal_show_help(), with two differences in functionality:
1. the rendered text help message output is sent to the HNP for
display (rather than outputting directly into the process' stderr
stream)
1. the HNP detects duplicate help messages and does not display them
(so that you don't see the same error message N times, once from
each of your N MPI processes); instead, it counts "new" instances
of the help message and displays a message every ~5 seconds when
there are new ones ("I got X new copies of the help message...")
opal_show_help and opal_output still exist, but they only output in
the current process. The intent for the new orte_* functions is that
they can apply job-level intelligence to the output. As such, we
recommend that all new ORTE and OMPI code use the new orte_*
functions, not thei opal_* functions.
=== New code ===
For ORTE and OMPI programmers, here's what you need to do differently
in new code:
* Do not include opal/util/show_help.h or opal/util/output.h.
Instead, include orte/util/output.h (this one header file has
declarations for both the orte_output() series of functions and
orte_show_help()).
* Effectively s/opal_output/orte_output/gi throughout your code.
Note that orte_output_open() takes a slightly different argument
list (as a way to pass data to the filtering stream -- see below),
so you if explicitly call opal_output_open(), you'll need to
slightly adapt to the new signature of orte_output_open().
* Literally s/opal_show_help/orte_show_help/. The function signature
is identical.
=== Notes ===
* orte_output'ing to stream 0 will do similar to what
opal_output'ing did, so leaving a hard-coded "0" as the first
argument is safe.
* For systems that do not use ORTE's RML or the HNP, the effect of
orte_output_* and orte_show_help will be identical to their opal
counterparts (the additional information passed to
orte_output_open() will be lost!). Indeed, the orte_* functions
simply become trivial wrappers to their opal_* counterparts. Note
that we have not tested this; the code is simple but it is quite
possible that we mucked something up.
= Filter Framework =
Messages sent view the new orte_* functions described above and
messages output via the IOF on the HNP will now optionally be passed
through a new "filter" framework before being output to
stdout/stderr. The "filter" OPAL MCA framework is intended to allow
preprocessing to messages before they are sent to their final
destinations. The first component that was written in the filter
framework was to create an XML stream, segregating all the messages
into different XML tags, etc. This will allow 3rd party tools to read
the stdout/stderr from the HNP and be able to know exactly what each
text message is (e.g., a help message, another OMPI infrastructure
message, stdout from the user process, stderr from the user process,
etc.).
Filtering is not active by default. Filter components must be
specifically requested, such as:
{{{
$ mpirun --mca filter xml ...
}}}
There can only be one filter component active.
= New MCA Parameters =
The new functionality described above introduces two new MCA
parameters:
* '''orte_base_help_aggregate''': Defaults to 1 (true), meaning that
help messages will be aggregated, as described above. If set to 0,
all help messages will be displayed, even if they are duplicates
(i.e., the original behavior).
* '''orte_base_show_output_recursions''': An MCA parameter to help
debug one of the known issues, described below. It is likely that
this MCA parameter will disappear before v1.3 final.
= Known Issues =
* The XML filter component is not complete. The current output from
this component is preliminary and not real XML. A bit more work
needs to be done to configure.m4 search for an appropriate XML
library/link it in/use it at run time.
* There are possible recursion loops in the orte_output() and
orte_show_help() functions -- e.g., if RML send calls orte_output()
or orte_show_help(). We have some ideas how to fix these, but
figured that it was ok to commit before feature freeze with known
issues. The code currently contains sub-optimal workarounds so
that this will not be a problem, but it would be good to actually
solve the problem rather than have hackish workarounds before v1.3 final.
This commit was SVN r18434.
2008-05-14 00:00:55 +04:00
|
|
|
/* detach from controlling terminal
|
|
|
|
* otherwise, remain attached so output can get to us
|
|
|
|
*/
|
|
|
|
if(!orte_debug_flag &&
|
|
|
|
!orte_debug_daemons_flag &&
|
|
|
|
orted_globals.daemonize) {
|
|
|
|
opal_daemon_init(NULL);
|
|
|
|
}
|
|
|
|
|
2008-02-28 04:57:57 +03:00
|
|
|
/* insert our contact info into our process_info struct so we
|
|
|
|
* have it for later use and set the local daemon field to our name
|
2007-07-12 23:53:18 +04:00
|
|
|
*/
|
2008-02-28 04:57:57 +03:00
|
|
|
orte_process_info.my_daemon_uri = orte_rml.get_contact_info();
|
|
|
|
ORTE_PROC_MY_DAEMON->jobid = ORTE_PROC_MY_NAME->jobid;
|
|
|
|
ORTE_PROC_MY_DAEMON->vpid = ORTE_PROC_MY_NAME->vpid;
|
|
|
|
|
|
|
|
/* if I am also the hnp, then update that contact info field too */
|
|
|
|
if (orte_process_info.hnp) {
|
|
|
|
orte_process_info.my_hnp_uri = orte_rml.get_contact_info();
|
|
|
|
ORTE_PROC_MY_HNP->jobid = ORTE_PROC_MY_NAME->jobid;
|
|
|
|
ORTE_PROC_MY_HNP->vpid = ORTE_PROC_MY_NAME->vpid;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* setup an event we can wait for to tell
|
|
|
|
* us to terminate - both normal and abnormal
|
|
|
|
* termination will call us here. Use the same exit
|
|
|
|
* fd as orterun so that orte_comm can wake either of us up
|
|
|
|
* since we share that code
|
|
|
|
*/
|
2008-10-16 18:21:37 +04:00
|
|
|
if (ORTE_SUCCESS != (ret = orte_wait_event(&orted_exit_event, &orte_exit, "orted_shutdown", shutdown_callback))) {
|
2007-07-12 23:53:18 +04:00
|
|
|
ORTE_ERROR_LOG(ret);
|
|
|
|
return ret;
|
|
|
|
}
|
2008-02-28 04:57:57 +03:00
|
|
|
|
Fix a potential, albeit perhaps esoteric, race condition that can occur for fast HNP's, slow orteds, and fast apps. Under those conditions, it is possible for the orted to be caught in its original send of contact info back to the HNP, and thus for the progress stack never to recover back to a high level. In those circumstances, the orted can "hang" when trying to exit.
Add a new function to opal_progress that tells us our recursion depth to support that solution.
Yes, I know this sounds picky, but good ol' Jeff managed to make it happen by driving his cluster near to death...
Also ensure that we declare "failed" for the daemon job when daemons fail instead of the application job. This is important so that orte knows that it cannot use xcast to tell daemons to "exit", nor should it expect all daemons to respond. Otherwise, it is possible to hang.
After lots of testing, decide to default (again) to slurm detecting failed orteds. This proved necessary to avoid rather annoying hangs that were difficult to recover from. There are conditions where slurm will fail to launch all daemons (slurm folks are working on it), and yet again, good ol' Jeff managed to find both of them.
Thanks you Jeff! :-/
This commit was SVN r18611.
2008-06-06 23:36:27 +04:00
|
|
|
/* setup the primary daemon command receive function */
|
2008-02-28 04:57:57 +03:00
|
|
|
ret = orte_rml.recv_buffer_nb(ORTE_NAME_WILDCARD, ORTE_RML_TAG_DAEMON,
|
|
|
|
ORTE_RML_NON_PERSISTENT, orte_daemon_recv, NULL);
|
2007-07-12 23:53:18 +04:00
|
|
|
if (ret != ORTE_SUCCESS && ret != ORTE_ERR_NOT_IMPLEMENTED) {
|
|
|
|
ORTE_ERROR_LOG(ret);
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Set signal handlers to catch kill signals so we can properly clean up
|
|
|
|
* after ourselves.
|
|
|
|
*/
|
|
|
|
opal_event_set(&term_handler, SIGTERM, OPAL_EV_SIGNAL,
|
2008-08-05 19:09:29 +04:00
|
|
|
shutdown_signal, NULL);
|
2007-07-12 23:53:18 +04:00
|
|
|
opal_event_add(&term_handler, NULL);
|
|
|
|
opal_event_set(&int_handler, SIGINT, OPAL_EV_SIGNAL,
|
2008-08-05 19:09:29 +04:00
|
|
|
shutdown_signal, NULL);
|
2007-07-12 23:53:18 +04:00
|
|
|
opal_event_add(&int_handler, NULL);
|
|
|
|
|
2007-09-12 18:32:31 +04:00
|
|
|
#ifndef __WINDOWS__
|
|
|
|
/** setup callbacks for signals we should ignore */
|
|
|
|
opal_signal_set(&sigusr1_handler, SIGUSR1,
|
|
|
|
signal_callback, &sigusr1_handler);
|
|
|
|
opal_signal_add(&sigusr1_handler, NULL);
|
|
|
|
opal_signal_set(&sigusr2_handler, SIGUSR2,
|
|
|
|
signal_callback, &sigusr2_handler);
|
|
|
|
opal_signal_add(&sigusr2_handler, NULL);
|
|
|
|
#endif /* __WINDOWS__ */
|
|
|
|
|
2007-07-12 23:53:18 +04:00
|
|
|
/* setup stdout/stderr */
|
|
|
|
if (orte_debug_daemons_file_flag) {
|
|
|
|
/* if we are debugging to a file, then send stdout/stderr to
|
|
|
|
* the orted log file
|
|
|
|
*/
|
|
|
|
|
|
|
|
/* get my jobid */
|
2008-02-28 04:57:57 +03:00
|
|
|
if (ORTE_SUCCESS != (ret = orte_util_convert_jobid_to_string(&jobidstring,
|
|
|
|
ORTE_PROC_MY_NAME->jobid))) {
|
2007-07-12 23:53:18 +04:00
|
|
|
ORTE_ERROR_LOG(ret);
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* define a log file name in the session directory */
|
|
|
|
sprintf(log_file, "output-orted-%s-%s.log",
|
2008-03-24 02:10:15 +03:00
|
|
|
jobidstring, orte_process_info.nodename);
|
2007-07-12 23:53:18 +04:00
|
|
|
log_path = opal_os_path(false,
|
|
|
|
orte_process_info.tmpdir_base,
|
|
|
|
orte_process_info.top_session_dir,
|
|
|
|
log_file,
|
|
|
|
NULL);
|
|
|
|
|
|
|
|
fd = open(log_path, O_RDWR|O_CREAT|O_TRUNC, 0640);
|
|
|
|
if (fd < 0) {
|
|
|
|
/* couldn't open the file for some reason, so
|
|
|
|
* just connect everything to /dev/null
|
|
|
|
*/
|
|
|
|
fd = open("/dev/null", O_RDWR|O_CREAT|O_TRUNC, 0666);
|
|
|
|
} else {
|
|
|
|
dup2(fd, STDOUT_FILENO);
|
|
|
|
dup2(fd, STDERR_FILENO);
|
|
|
|
if(fd != STDOUT_FILENO && fd != STDERR_FILENO) {
|
|
|
|
close(fd);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/* output a message indicating we are alive, our name, and our pid
|
|
|
|
* for debugging purposes
|
|
|
|
*/
|
|
|
|
if (orte_debug_daemons_flag) {
|
2007-07-20 06:34:29 +04:00
|
|
|
fprintf(stderr, "Daemon %s checking in as pid %ld on host %s\n",
|
2008-02-28 04:57:57 +03:00
|
|
|
ORTE_NAME_PRINT(ORTE_PROC_MY_NAME), (long)orte_process_info.pid,
|
2008-03-24 02:10:15 +03:00
|
|
|
orte_process_info.nodename);
|
2007-07-12 23:53:18 +04:00
|
|
|
}
|
|
|
|
|
2007-10-06 13:24:51 +04:00
|
|
|
/* We actually do *not* want the orted to voluntarily yield() the
|
|
|
|
processor more than necessary. The orted already blocks when
|
|
|
|
it is doing nothing, so it doesn't use any more CPU cycles than
|
|
|
|
it should; but when it *is* doing something, we do not want it
|
|
|
|
to be unnecessarily delayed because it voluntarily yielded the
|
|
|
|
processor in the middle of its work.
|
|
|
|
|
|
|
|
For example: when a message arrives at the orted, we want the
|
|
|
|
OS to wake up the orted in a timely fashion (which most OS's
|
|
|
|
seem good about doing) and then we want the orted to process
|
|
|
|
the message as fast as possible. If the orted yields and lets
|
|
|
|
aggressive MPI applications get the processor back, it may be a
|
|
|
|
long time before the OS schedules the orted to run again
|
|
|
|
(particularly if there is no IO event to wake it up). Hence,
|
|
|
|
routed OOB messages (for example) may be significantly delayed
|
|
|
|
before being delivered to MPI processes, which can be
|
|
|
|
problematic in some scenarios (e.g., COMM_SPAWN, BTL's that
|
|
|
|
require OOB messages for wireup, etc.). */
|
|
|
|
opal_progress_set_yield_when_idle(false);
|
2007-07-12 23:53:18 +04:00
|
|
|
|
2007-10-15 19:41:36 +04:00
|
|
|
/* Change the default behavior of libevent such that we want to
|
|
|
|
continually block rather than blocking for the default timeout
|
|
|
|
and then looping around the progress engine again. There
|
|
|
|
should be nothing in the orted that cannot block in libevent
|
|
|
|
until "something" happens (i.e., there's no need to keep
|
|
|
|
cycling through progress because the only things that should
|
|
|
|
happen will happen in libevent). This is a minor optimization,
|
|
|
|
but what the heck... :-) */
|
|
|
|
opal_progress_set_event_flag(OPAL_EVLOOP_ONCE);
|
|
|
|
|
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
|
|
|
/* if requested, obtain and report a new process name and my uri to the indicated pipe */
|
2007-07-12 23:53:18 +04:00
|
|
|
if (orted_globals.uri_pipe > 0) {
|
2008-02-28 04:57:57 +03:00
|
|
|
orte_job_t *jdata;
|
|
|
|
orte_proc_t *proc;
|
|
|
|
orte_node_t **nodes;
|
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
|
|
|
orte_app_context_t *app;
|
2008-02-28 04:57:57 +03:00
|
|
|
char *tmp, *nptr;
|
|
|
|
int rc;
|
|
|
|
|
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
|
|
|
/* setup the singleton's job */
|
2008-02-28 04:57:57 +03:00
|
|
|
jdata = OBJ_NEW(orte_job_t);
|
|
|
|
orte_plm_base_create_jobid(&jdata->jobid);
|
2008-02-28 08:32:23 +03:00
|
|
|
opal_pointer_array_add(orte_job_data, jdata);
|
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-02-28 04:57:57 +03:00
|
|
|
/* setup an app_context for the singleton */
|
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
|
|
|
app = OBJ_NEW(orte_app_context_t);
|
|
|
|
app->app = strdup("singleton");
|
|
|
|
app->num_procs = 1;
|
2008-02-28 08:32:23 +03:00
|
|
|
opal_pointer_array_add(jdata->apps, app);
|
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-02-28 04:57:57 +03:00
|
|
|
/* run our local allocator to read the available
|
|
|
|
* allocation in case this singleton decides to
|
|
|
|
* comm_spawn other procs
|
|
|
|
*/
|
|
|
|
if (ORTE_SUCCESS != (rc = orte_ras.allocate(jdata))) {
|
|
|
|
ORTE_ERROR_LOG(rc);
|
|
|
|
/* don't quit as this would cause the singleton
|
|
|
|
* to hang!
|
|
|
|
*/
|
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-02-28 04:57:57 +03:00
|
|
|
nodes = (orte_node_t**)orte_node_pool->addr;
|
|
|
|
|
|
|
|
/* setup a proc object for the singleton - since we
|
|
|
|
* -must- be the HNP, and therefore we stored our
|
|
|
|
* node on the global node pool, and since the singleton
|
|
|
|
* -must- be on the same node as us, indicate that
|
|
|
|
*/
|
|
|
|
proc = OBJ_NEW(orte_proc_t);
|
|
|
|
proc->name.jobid = jdata->jobid;
|
|
|
|
proc->name.vpid = 0;
|
|
|
|
proc->state = ORTE_PROC_STATE_RUNNING;
|
|
|
|
proc->app_idx = 0;
|
|
|
|
proc->node = nodes[0]; /* hnp node must be there */
|
|
|
|
OBJ_RETAIN(nodes[0]); /* keep accounting straight */
|
2008-02-28 08:32:23 +03:00
|
|
|
opal_pointer_array_add(jdata->procs, proc);
|
2008-02-28 04:57:57 +03:00
|
|
|
jdata->num_procs = 1;
|
|
|
|
|
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
|
|
|
/* create a string that contains our uri + the singleton's name */
|
2008-02-28 04:57:57 +03:00
|
|
|
orte_util_convert_process_name_to_string(&nptr, &proc->name);
|
|
|
|
asprintf(&tmp, "%s[%s]", orte_process_info.my_daemon_uri, nptr);
|
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
|
|
|
free(nptr);
|
|
|
|
|
|
|
|
/* pass that info to the singleton */
|
|
|
|
write(orted_globals.uri_pipe, tmp, strlen(tmp)+1); /* need to add 1 to get the NULL */
|
|
|
|
|
|
|
|
/* cleanup */
|
|
|
|
free(tmp);
|
2007-07-12 23:53:18 +04:00
|
|
|
}
|
|
|
|
|
|
|
|
/* if we were given a pipe to monitor for singleton termination, set that up */
|
|
|
|
if (orted_globals.singleton_died_pipe > 0) {
|
|
|
|
/* register shutdown handler */
|
|
|
|
opal_event_set(&pipe_handler,
|
|
|
|
orted_globals.singleton_died_pipe,
|
|
|
|
OPAL_EV_READ|OPAL_EV_PERSIST,
|
|
|
|
shutdown_callback,
|
|
|
|
&orted_globals.singleton_died_pipe);
|
|
|
|
opal_event_add(&pipe_handler, NULL);
|
|
|
|
}
|
|
|
|
|
2008-02-28 04:57:57 +03:00
|
|
|
/* if we are not the HNP...the only time we will be an HNP
|
|
|
|
* is if we are launched by a singleton to provide support
|
|
|
|
* for it
|
|
|
|
*/
|
|
|
|
if (!orte_process_info.hnp) {
|
2007-07-12 23:53:18 +04:00
|
|
|
/* send the information to the orted report-back point - this function
|
2008-02-28 04:57:57 +03:00
|
|
|
* will process the data, but also counts the number of
|
2007-07-12 23:53:18 +04:00
|
|
|
* orteds that reported back so the launch procedure can continue.
|
|
|
|
* We need to do this at the last possible second as the HNP
|
|
|
|
* can turn right around and begin issuing orders to us
|
|
|
|
*/
|
2008-04-14 22:26:08 +04:00
|
|
|
|
2008-02-28 04:57:57 +03:00
|
|
|
buffer = OBJ_NEW(opal_buffer_t);
|
2009-01-30 21:31:43 +03:00
|
|
|
/* for now, always include our contact info, even if we are using
|
|
|
|
* static ports. Eventually, this will be removed
|
2008-04-30 23:49:53 +04:00
|
|
|
*/
|
2009-01-30 21:31:43 +03:00
|
|
|
rml_uri = orte_rml.get_contact_info();
|
|
|
|
if (ORTE_SUCCESS != (ret = opal_dss.pack(buffer, &rml_uri, 1, OPAL_STRING))) {
|
|
|
|
ORTE_ERROR_LOG(ret);
|
|
|
|
OBJ_RELEASE(buffer);
|
|
|
|
return ret;
|
2008-04-30 23:49:53 +04:00
|
|
|
}
|
|
|
|
/* send our architecture */
|
|
|
|
if (ORTE_SUCCESS != (ret = opal_dss.pack(buffer, &orte_process_info.arch, 1, OPAL_INT32))) {
|
2008-02-28 04:57:57 +03:00
|
|
|
ORTE_ERROR_LOG(ret);
|
|
|
|
OBJ_RELEASE(buffer);
|
|
|
|
return ret;
|
|
|
|
}
|
2009-01-08 17:27:52 +03:00
|
|
|
if (orte_timing) {
|
|
|
|
int64_t secs, usecs;
|
|
|
|
/* add our start time */
|
|
|
|
secs = starttime.tv_sec;
|
|
|
|
if (ORTE_SUCCESS != (ret = opal_dss.pack(buffer, &secs, 1, OPAL_INT64))) {
|
|
|
|
ORTE_ERROR_LOG(ret);
|
|
|
|
OBJ_RELEASE(buffer);
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
usecs = starttime.tv_usec;
|
|
|
|
if (ORTE_SUCCESS != (ret = opal_dss.pack(buffer, &usecs, 1, OPAL_INT64))) {
|
|
|
|
ORTE_ERROR_LOG(ret);
|
|
|
|
OBJ_RELEASE(buffer);
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
/* get and send our setup time */
|
|
|
|
gettimeofday(&setuptime, NULL);
|
|
|
|
secs = setuptime.tv_sec - starttime.tv_sec;
|
|
|
|
if (starttime.tv_usec <= setuptime.tv_usec) {
|
|
|
|
usecs = setuptime.tv_usec - starttime.tv_usec;
|
|
|
|
} else {
|
|
|
|
secs--;
|
|
|
|
usecs = 1000000 - starttime.tv_usec + setuptime.tv_usec;
|
|
|
|
}
|
|
|
|
if (ORTE_SUCCESS != (ret = opal_dss.pack(buffer, &secs, 1, OPAL_INT64))) {
|
|
|
|
ORTE_ERROR_LOG(ret);
|
|
|
|
OBJ_RELEASE(buffer);
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
if (ORTE_SUCCESS != (ret = opal_dss.pack(buffer, &usecs, 1, OPAL_INT64))) {
|
|
|
|
ORTE_ERROR_LOG(ret);
|
|
|
|
OBJ_RELEASE(buffer);
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
/* include the actual timestamp so the HNP can figure out how
|
|
|
|
* long it took for this message to arrive
|
|
|
|
*/
|
|
|
|
secs = setuptime.tv_sec;
|
|
|
|
if (ORTE_SUCCESS != (ret = opal_dss.pack(buffer, &secs, 1, OPAL_INT64))) {
|
|
|
|
ORTE_ERROR_LOG(ret);
|
|
|
|
OBJ_RELEASE(buffer);
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
usecs = setuptime.tv_usec;
|
|
|
|
if (ORTE_SUCCESS != (ret = opal_dss.pack(buffer, &usecs, 1, OPAL_INT64))) {
|
|
|
|
ORTE_ERROR_LOG(ret);
|
|
|
|
OBJ_RELEASE(buffer);
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
}
|
2008-05-01 23:19:34 +04:00
|
|
|
if (0 > (ret = orte_rml.send_buffer(ORTE_PROC_MY_HNP, buffer,
|
2007-07-12 23:53:18 +04:00
|
|
|
ORTE_RML_TAG_ORTED_CALLBACK, 0))) {
|
|
|
|
ORTE_ERROR_LOG(ret);
|
|
|
|
OBJ_RELEASE(buffer);
|
|
|
|
return ret;
|
|
|
|
}
|
2008-02-28 04:57:57 +03:00
|
|
|
OBJ_RELEASE(buffer); /* done with this */
|
2007-07-12 23:53:18 +04:00
|
|
|
}
|
|
|
|
|
|
|
|
if (orte_debug_daemons_flag) {
|
2008-06-09 18:53:58 +04:00
|
|
|
opal_output(0, "%s orted: up and running - waiting for commands!", ORTE_NAME_PRINT(ORTE_PROC_MY_NAME));
|
2007-07-12 23:53:18 +04:00
|
|
|
}
|
|
|
|
|
2008-06-03 01:46:34 +04:00
|
|
|
/* if we were told to do a heartbeat, then setup to do so */
|
|
|
|
if (0 < orted_globals.heartbeat) {
|
2008-12-10 23:40:47 +03:00
|
|
|
ORTE_TIMER_EVENT(orted_globals.heartbeat, 0, orte_plm_base_heartbeat);
|
2008-06-03 01:46:34 +04:00
|
|
|
}
|
|
|
|
|
2008-02-28 04:57:57 +03:00
|
|
|
/* wait to hear we are done */
|
|
|
|
opal_event_dispatch();
|
2007-07-12 23:53:18 +04:00
|
|
|
|
2008-02-28 04:57:57 +03:00
|
|
|
/* should never get here, but if we do... */
|
|
|
|
|
|
|
|
/* cleanup any lingering session directories */
|
|
|
|
orte_session_dir_cleanup(ORTE_JOBID_WILDCARD);
|
|
|
|
|
2008-08-06 15:31:06 +04:00
|
|
|
/* cleanup the triggers */
|
|
|
|
OBJ_DESTRUCT(&orte_exit);
|
|
|
|
|
2008-02-28 04:57:57 +03:00
|
|
|
/* Finalize and clean up ourselves */
|
2008-06-03 01:46:34 +04:00
|
|
|
ret = orte_finalize();
|
2008-02-28 04:57:57 +03:00
|
|
|
return ret;
|
|
|
|
}
|
2007-07-12 23:53:18 +04:00
|
|
|
|
2008-08-05 19:09:29 +04:00
|
|
|
static void shutdown_signal(int fd, short flags, void *arg)
|
|
|
|
{
|
|
|
|
/* trigger the call to shutdown callback to protect
|
|
|
|
* against race conditions - the trigger event will
|
|
|
|
* check the one-time lock
|
|
|
|
*/
|
|
|
|
orte_trigger_event(&orte_exit);
|
|
|
|
}
|
|
|
|
|
2008-02-28 04:57:57 +03:00
|
|
|
static void shutdown_callback(int fd, short flags, void *arg)
|
|
|
|
{
|
|
|
|
int ret;
|
|
|
|
|
|
|
|
if (NULL != arg) {
|
|
|
|
/* it's the singleton pipe... remove that handler */
|
|
|
|
opal_event_del(&pipe_handler);
|
|
|
|
}
|
|
|
|
|
2007-07-12 23:53:18 +04:00
|
|
|
if (orte_debug_daemons_flag) {
|
2008-06-09 18:53:58 +04:00
|
|
|
opal_output(0, "%s orted: finalizing", ORTE_NAME_PRINT(ORTE_PROC_MY_NAME));
|
2007-07-12 23:53:18 +04:00
|
|
|
}
|
2008-02-28 04:57:57 +03:00
|
|
|
|
2007-07-12 23:53:18 +04:00
|
|
|
/* cleanup */
|
|
|
|
if (NULL != log_path) {
|
|
|
|
unlink(log_path);
|
|
|
|
}
|
2008-02-28 04:57:57 +03:00
|
|
|
|
2007-07-12 23:53:18 +04:00
|
|
|
/* make sure our local procs are dead - but don't update their state
|
2008-02-28 04:57:57 +03:00
|
|
|
* on the HNP as this may be redundant
|
|
|
|
*/
|
2007-07-12 23:53:18 +04:00
|
|
|
orte_odls.kill_local_procs(ORTE_JOBID_WILDCARD, false);
|
2008-02-28 04:57:57 +03:00
|
|
|
|
2008-08-06 15:31:06 +04:00
|
|
|
/* cleanup the triggers */
|
|
|
|
OBJ_DESTRUCT(&orte_exit);
|
|
|
|
|
|
|
|
/* if we were ordered to abort, do so */
|
|
|
|
if (orted_globals.abort) {
|
|
|
|
opal_output(0, "%s is executing clean abort", ORTE_NAME_PRINT(ORTE_PROC_MY_NAME));
|
|
|
|
/* do -not- call finalize as this will send a message to the HNP
|
|
|
|
* indicating clean termination! Instead, just forcibly cleanup
|
|
|
|
* the local session_dir tree and abort
|
|
|
|
*/
|
|
|
|
orte_session_dir_cleanup(ORTE_JOBID_WILDCARD);
|
|
|
|
abort();
|
|
|
|
} else if ((int)ORTE_PROC_MY_NAME->vpid == orted_globals.fail) {
|
|
|
|
opal_output(0, "%s is executing clean abnormal termination", ORTE_NAME_PRINT(ORTE_PROC_MY_NAME));
|
|
|
|
/* do -not- call finalize as this will send a message to the HNP
|
|
|
|
* indicating clean termination! Instead, just forcibly cleanup
|
|
|
|
* the local session_dir tree and exit
|
|
|
|
*/
|
|
|
|
orte_session_dir_cleanup(ORTE_JOBID_WILDCARD);
|
|
|
|
exit(ORTE_ERROR_DEFAULT_EXIT_CODE);
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Finalize and clean up ourselves */
|
2008-06-03 01:46:34 +04:00
|
|
|
ret = orte_finalize();
|
2007-07-12 23:53:18 +04:00
|
|
|
exit(ret);
|
|
|
|
}
|
|
|
|
|
2007-09-12 18:32:31 +04:00
|
|
|
static void signal_callback(int fd, short event, void *arg)
|
|
|
|
{
|
|
|
|
/* just ignore these signals */
|
|
|
|
}
|