2007-04-23 22:28:20 +04:00
|
|
|
/*
|
2010-03-13 02:57:50 +03:00
|
|
|
* Copyright (c) 2004-2010 The Trustees of Indiana University and Indiana
|
2007-04-23 22:28:20 +04:00
|
|
|
* University Research and Technology
|
|
|
|
|
* Corporation. All rights reserved.
|
2011-06-24 00:38:02 +04:00
|
|
|
* Copyright (c) 2004-2011 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.
|
At long last, the fabled revision to the affinity system has arrived. A more detailed explanation of how this all works will be presented here:
https://svn.open-mpi.org/trac/ompi/wiki/ProcessPlacement
The wiki page is incomplete at the moment, but I hope to complete it over the next few days. I will provide updates on the devel list. As the wiki page states, the default and most commonly used options remain unchanged (except as noted below). New, esoteric and complex options have been added, but unless you are a true masochist, you are unlikely to use many of them beyond perhaps an initial curiosity-motivated experimentation.
In a nutshell, this commit revamps the map/rank/bind procedure to take into account topology info on the compute nodes. I have, for the most part, preserved the default behaviors, with three notable exceptions:
1. I have at long last bowed my head in submission to the system admin's of managed clusters. For years, they have complained about our default of allowing users to oversubscribe nodes - i.e., to run more processes on a node than allocated slots. Accordingly, I have modified the default behavior: if you are running off of hostfile/dash-host allocated nodes, then the default is to allow oversubscription. If you are running off of RM-allocated nodes, then the default is to NOT allow oversubscription. Flags to override these behaviors are provided, so this only affects the default behavior.
2. both cpus/rank and stride have been removed. The latter was demanded by those who didn't understand the purpose behind it - and I agreed as the users who requested it are no longer using it. The former was removed temporarily pending implementation.
3. vm launch is now the sole method for starting OMPI. It was just too darned hard to maintain multiple launch procedures - maybe someday, provided someone can demonstrate a reason to do so.
As Jeff stated, it is impossible to fully test a change of this size. I have tested it on Linux and Mac, covering all the default and simple options, singletons, and comm_spawn. That said, I'm sure others will find problems, so I'll be watching MTT results until this stabilizes.
This commit was SVN r25476.
2011-11-15 07:40:11 +04:00
|
|
|
* Copyright (c) 2007-2011 Cisco Systems, Inc. All rights reserved.
|
2013-01-18 09:00:05 +04:00
|
|
|
* Copyright (c) 2007-2013 Los Alamos National Security, LLC. All rights
|
2007-07-12 23:53:18 +04:00
|
|
|
* reserved.
|
Repair the tree spawn. The problem seems to come from the fact
that now the HNP send the messages using the routed component. In the case
of tree spawn, when a intermediary node spawn a child it doesn't know how
to forward a message to it, so when the node-map message is coming from
the HNP (as there is nothing yet in the contact/routing table) the message
is sent back the way it came. As a result the node-map message keeps jumping
between the HNP and the first level orteds.
The solution is to add a new option to the children orte_parent_uri, which
is only set when the orted is _not_ directly spawned by the HNP. When this
option is present on the argument list, the orted will add the parent to
its routing, and force the parent to update his routes (by sending the URI).
With this approach, the routing tree is build in same time as the processes
are spawned, and all messages from the HNP can be routed to the leaves.
However, this is far from an optimal solution. Right now, this so called tree
spawn, only spawn the children in a tree without doing anything about the
"connect back to the HNP" step. The HNP is flooded with reports from all the
orted. The total number of messages is higher than in the non tree startup
scheme, so we do not expect this approach to be scalable in the current
incarnation. A complete overhaul of the tree startup is required in order
improve the scalability. Stay tuned!
This commit was SVN r21504.
2009-06-24 02:10:25 +04:00
|
|
|
* Copyright (c) 2009 Institut National de Recherche en Informatique
|
|
|
|
|
* et Automatique. All rights reserved.
|
2010-08-09 23:28:56 +04:00
|
|
|
* Copyright (c) 2010 Oracle and/or its affiliates. All rights reserved.
|
2007-04-23 22:28:20 +04:00
|
|
|
* $COPYRIGHT$
|
|
|
|
|
*
|
|
|
|
|
* Additional copyrights may follow
|
|
|
|
|
*
|
|
|
|
|
* $HEADER$
|
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
#include "orte_config.h"
|
2010-07-18 01:03:27 +04:00
|
|
|
#include "orte/constants.h"
|
2009-03-13 05:10:32 +03:00
|
|
|
|
|
|
|
|
#ifdef HAVE_STRING_H
|
|
|
|
|
#include <string.h>
|
|
|
|
|
#endif
|
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
|
|
|
|
|
|
|
|
|
Update libevent to the 2.0 series, currently at 2.0.7rc. We will update to their final release when it becomes available. Currently known errors exist in unused portions of the libevent code. This revision passes the IBM test suite on a Linux machine and on a standalone Mac.
This is a fairly intrusive change, but outside of the moving of opal/event to opal/mca/event, the only changes involved (a) changing all calls to opal_event functions to reflect the new framework instead, and (b) ensuring that all opal_event_t objects are properly constructed since they are now true opal_objects.
Note: Shiqing has just returned from vacation and has not yet had a chance to complete the Windows integration. Thus, this commit almost certainly breaks Windows support on the trunk. However, I want this to have a chance to soak for as long as possible before I become less available a week from today (going to be at a class for 5 days, and thus will only be sparingly available) so we can find and fix any problems.
Biggest change is moving the libevent code from opal/event to a new opal/mca/event framework. This was done to make it much easier to update libevent in the future. New versions can be inserted as a new component and tested in parallel with the current version until validated, then we can remove the earlier version if we so choose. This is a statically built framework ala installdirs, so only one component will build at a time. There is no selection logic - the sole compiled component simply loads its function pointers into the opal_event struct.
I have gone thru the code base and converted all the libevent calls I could find. However, I cannot compile nor test every environment. It is therefore quite likely that errors remain in the system. Please keep an eye open for two things:
1. compile-time errors: these will be obvious as calls to the old functions (e.g., opal_evtimer_new) must be replaced by the new framework APIs (e.g., opal_event.evtimer_new)
2. run-time errors: these will likely show up as segfaults due to missing constructors on opal_event_t objects. It appears that it became a typical practice for people to "init" an opal_event_t by simply using memset to zero it out. This will no longer work - you must either OBJ_NEW or OBJ_CONSTRUCT an opal_event_t. I tried to catch these cases, but may have missed some. Believe me, you'll know when you hit it.
There is also the issue of the new libevent "no recursion" behavior. As I described on a recent email, we will have to discuss this and figure out what, if anything, we need to do.
This commit was SVN r23925.
2010-10-24 22:35:54 +04:00
|
|
|
#include "opal/mca/event/event.h"
|
2007-04-23 22:28:20 +04:00
|
|
|
#include "opal/mca/base/base.h"
|
2009-02-14 05:26:12 +03:00
|
|
|
#include "opal/util/output.h"
|
2007-07-12 23:53:18 +04:00
|
|
|
#include "opal/util/cmd_line.h"
|
2012-11-16 08:04:29 +04:00
|
|
|
#include "opal/util/if.h"
|
2013-01-18 09:00:05 +04:00
|
|
|
#include "opal/util/net.h"
|
2007-07-12 23:53:18 +04:00
|
|
|
#include "opal/util/opal_environ.h"
|
|
|
|
|
#include "opal/util/os_path.h"
|
|
|
|
|
#include "opal/util/printf.h"
|
|
|
|
|
#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"
|
2011-09-11 23:02:24 +04:00
|
|
|
#include "opal/mca/hwloc/hwloc.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"
|
2010-03-23 23:47:41 +03:00
|
|
|
#include "orte/util/nidmap.h"
|
Repair the tree spawn. The problem seems to come from the fact
that now the HNP send the messages using the routed component. In the case
of tree spawn, when a intermediary node spawn a child it doesn't know how
to forward a message to it, so when the node-map message is coming from
the HNP (as there is nothing yet in the contact/routing table) the message
is sent back the way it came. As a result the node-map message keeps jumping
between the HNP and the first level orteds.
The solution is to add a new option to the children orte_parent_uri, which
is only set when the orted is _not_ directly spawned by the HNP. When this
option is present on the argument list, the orted will add the parent to
its routing, and force the parent to update his routes (by sending the URI).
With this approach, the routing tree is build in same time as the processes
are spawned, and all messages from the HNP can be routed to the leaves.
However, this is far from an optimal solution. Right now, this so called tree
spawn, only spawn the children in a tree without doing anything about the
"connect back to the HNP" step. The HNP is flooded with reports from all the
orted. The total number of messages is higher than in the non tree startup
scheme, so we do not expect this approach to be scalable in the current
incarnation. A complete overhaul of the tree startup is required in order
improve the scalability. Stay tuned!
This commit was SVN r21504.
2009-06-24 02:10:25 +04:00
|
|
|
#include "orte/mca/rml/base/rml_contact.h"
|
2007-04-23 22:28:20 +04:00
|
|
|
|
|
|
|
|
#include "orte/mca/errmgr/errmgr.h"
|
2012-04-06 18:23:13 +04:00
|
|
|
#include "orte/mca/ess/ess.h"
|
2009-05-11 18:11:44 +04:00
|
|
|
#include "orte/mca/grpcomm/grpcomm.h"
|
2012-04-10 23:08:54 +04:00
|
|
|
#include "orte/mca/grpcomm/base/base.h"
|
2007-04-23 22:28:20 +04:00
|
|
|
#include "orte/mca/rml/rml.h"
|
2009-02-14 05:26:12 +03:00
|
|
|
#include "orte/mca/rml/rml_types.h"
|
2007-07-12 23:53:18 +04:00
|
|
|
#include "orte/mca/odls/odls.h"
|
2010-03-23 23:47:41 +03:00
|
|
|
#include "orte/mca/odls/base/odls_private.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"
|
2010-07-18 06:48:17 +04:00
|
|
|
#include "orte/mca/rmaps/rmaps_types.h"
|
2012-04-06 18:23:13 +04:00
|
|
|
#include "orte/mca/state/state.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"
|
2010-07-18 01:03:27 +04:00
|
|
|
#include "orte/runtime/orte_locks.h"
|
|
|
|
|
#include "orte/runtime/orte_quit.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
|
|
|
|
|
*/
|
2012-04-06 18:23:13 +04:00
|
|
|
static opal_event_t *pipe_handler;
|
2007-07-12 23:53:18 +04:00
|
|
|
static void shutdown_callback(int fd, short flags, void *arg);
|
2012-04-06 18:23:13 +04:00
|
|
|
static void pipe_closed(int fd, short flags, 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;
|
2012-05-03 01:00:22 +04:00
|
|
|
bool mapreduce;
|
2012-06-22 01:29:28 +04:00
|
|
|
bool tree_spawn;
|
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 */
|
2012-10-30 23:45:18 +04:00
|
|
|
{ NULL, 'h', NULL, "help", 0,
|
2007-07-12 23:53:18 +04:00
|
|
|
&orted_globals.help, OPAL_CMD_LINE_TYPE_BOOL,
|
|
|
|
|
"This help message" },
|
|
|
|
|
|
2012-10-30 23:45:18 +04:00
|
|
|
{ "orte_daemon_spin", 's', NULL, "spin", 0,
|
2008-07-02 05:46:58 +04:00
|
|
|
&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" },
|
|
|
|
|
|
2012-10-30 23:45:18 +04:00
|
|
|
{ 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" },
|
|
|
|
|
|
2012-10-30 23:45:18 +04:00
|
|
|
{ NULL, '\0', NULL, "debug-failure-delay", 1,
|
2008-06-03 01:46:34 +04:00
|
|
|
&orted_globals.fail_delay, OPAL_CMD_LINE_TYPE_INT,
|
|
|
|
|
"Have the orted specified for failure delay for the provided number of seconds before failing" },
|
|
|
|
|
|
2012-10-30 23:45:18 +04:00
|
|
|
{ "orte_debug", '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
|
|
|
|
2012-10-30 23:45:18 +04:00
|
|
|
{ "orte_daemonize", '\0', NULL, "daemonize", 0,
|
2008-02-28 04:57:57 +03:00
|
|
|
&orted_globals.daemonize, OPAL_CMD_LINE_TYPE_BOOL,
|
|
|
|
|
"Daemonize the orted into the background" },
|
2007-07-12 23:53:18 +04:00
|
|
|
|
2012-10-30 23:45: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" },
|
|
|
|
|
|
2012-10-30 23:45:18 +04:00
|
|
|
{ "orte_debug_daemons_file", '\0', NULL, "debug-daemons-file", 0,
|
2007-07-12 23:53:18 +04:00
|
|
|
NULL, OPAL_CMD_LINE_TYPE_BOOL,
|
|
|
|
|
"Enable debugging of OpenRTE daemons, storing output in files" },
|
|
|
|
|
|
2012-10-30 23:45:18 +04:00
|
|
|
{ NULL, '\0', NULL, "hnp", 0,
|
2008-02-28 04:57:57 +03:00
|
|
|
&orted_globals.hnp, OPAL_CMD_LINE_TYPE_BOOL,
|
|
|
|
|
"Direct the orted to act as the HNP"},
|
|
|
|
|
|
2012-10-30 23:45:18 +04:00
|
|
|
{ "orte_hnp_uri", '\0', NULL, "hnp-uri", 1,
|
2008-02-28 04:57:57 +03:00
|
|
|
NULL, OPAL_CMD_LINE_TYPE_STRING,
|
|
|
|
|
"URI for the HNP"},
|
|
|
|
|
|
2012-10-30 23:45:18 +04:00
|
|
|
{ "orte_parent_uri", '\0', NULL, "parent-uri", 1,
|
Repair the tree spawn. The problem seems to come from the fact
that now the HNP send the messages using the routed component. In the case
of tree spawn, when a intermediary node spawn a child it doesn't know how
to forward a message to it, so when the node-map message is coming from
the HNP (as there is nothing yet in the contact/routing table) the message
is sent back the way it came. As a result the node-map message keeps jumping
between the HNP and the first level orteds.
The solution is to add a new option to the children orte_parent_uri, which
is only set when the orted is _not_ directly spawned by the HNP. When this
option is present on the argument list, the orted will add the parent to
its routing, and force the parent to update his routes (by sending the URI).
With this approach, the routing tree is build in same time as the processes
are spawned, and all messages from the HNP can be routed to the leaves.
However, this is far from an optimal solution. Right now, this so called tree
spawn, only spawn the children in a tree without doing anything about the
"connect back to the HNP" step. The HNP is flooded with reports from all the
orted. The total number of messages is higher than in the non tree startup
scheme, so we do not expect this approach to be scalable in the current
incarnation. A complete overhaul of the tree startup is required in order
improve the scalability. Stay tuned!
This commit was SVN r21504.
2009-06-24 02:10:25 +04:00
|
|
|
NULL, OPAL_CMD_LINE_TYPE_STRING,
|
|
|
|
|
"URI for the parent if tree launch is enabled."},
|
|
|
|
|
|
2012-10-30 23:45:18 +04:00
|
|
|
{ "orte_use_common_port", '\0', NULL, "use-common-port", 0,
|
2012-06-15 14:15:07 +04:00
|
|
|
NULL, OPAL_CMD_LINE_TYPE_BOOL,
|
|
|
|
|
"Use the same port as the HNP."},
|
|
|
|
|
|
2012-10-30 23:45:18 +04:00
|
|
|
{ NULL, '\0', NULL, "tree-spawn", 0,
|
2012-06-22 01:29:28 +04:00
|
|
|
&orted_globals.tree_spawn, OPAL_CMD_LINE_TYPE_BOOL,
|
|
|
|
|
"Tree spawn is underway"},
|
|
|
|
|
|
2012-10-30 23:45:18 +04:00
|
|
|
{ NULL, '\0', NULL, "set-sid", 0,
|
2007-07-12 23:53:18 +04:00
|
|
|
&orted_globals.set_sid, OPAL_CMD_LINE_TYPE_BOOL,
|
|
|
|
|
"Direct the orted to separate from the current session"},
|
|
|
|
|
|
2012-10-30 23:45:18 +04:00
|
|
|
{ "tmpdir_base", '\0', NULL, "tmpdir", 1,
|
2007-07-12 23:53:18 +04:00
|
|
|
NULL, OPAL_CMD_LINE_TYPE_STRING,
|
|
|
|
|
"Set the root for the session directory tree" },
|
|
|
|
|
|
2012-10-30 23:45:18 +04:00
|
|
|
{ NULL, '\0', NULL, "report-uri", 1,
|
2007-07-12 23:53:18 +04:00
|
|
|
&orted_globals.uri_pipe, OPAL_CMD_LINE_TYPE_INT,
|
|
|
|
|
"Report this process' uri on indicated pipe"},
|
|
|
|
|
|
2012-10-30 23:45:18 +04:00
|
|
|
{ NULL, '\0', NULL, "singleton-died-pipe", 1,
|
2007-07-12 23:53:18 +04:00
|
|
|
&orted_globals.singleton_died_pipe, OPAL_CMD_LINE_TYPE_INT,
|
|
|
|
|
"Watch on indicated pipe for singleton termination"},
|
|
|
|
|
|
2012-10-30 23:45:18 +04:00
|
|
|
{ "orte_output_filename", '\0', "output-filename", "output-filename", 1,
|
2009-02-03 23:06:05 +03:00
|
|
|
NULL, OPAL_CMD_LINE_TYPE_STRING,
|
|
|
|
|
"Redirect output from application processes into filename.rank" },
|
|
|
|
|
|
2012-10-30 23:45:18 +04:00
|
|
|
{ "orte_xterm", '\0', "xterm", "xterm", 1,
|
2009-02-03 23:06:05 +03:00
|
|
|
NULL, OPAL_CMD_LINE_TYPE_STRING,
|
|
|
|
|
"Create a new xterm window and display output from the specified ranks there" },
|
|
|
|
|
|
2012-10-30 23:45:18 +04:00
|
|
|
{ "orte_report_bindings", '\0', "report-bindings", "report-bindings", 0,
|
2009-09-28 07:17:15 +04:00
|
|
|
NULL, OPAL_CMD_LINE_TYPE_BOOL,
|
|
|
|
|
"Whether to report process bindings to stderr" },
|
|
|
|
|
|
2012-10-30 23:45:18 +04:00
|
|
|
{ "orte_node_regex", '\0', "nodes", "nodes", 1,
|
2011-07-07 22:54:30 +04:00
|
|
|
NULL, OPAL_CMD_LINE_TYPE_STRING,
|
|
|
|
|
"Regular expression defining nodes in system" },
|
|
|
|
|
|
At long last, the fabled revision to the affinity system has arrived. A more detailed explanation of how this all works will be presented here:
https://svn.open-mpi.org/trac/ompi/wiki/ProcessPlacement
The wiki page is incomplete at the moment, but I hope to complete it over the next few days. I will provide updates on the devel list. As the wiki page states, the default and most commonly used options remain unchanged (except as noted below). New, esoteric and complex options have been added, but unless you are a true masochist, you are unlikely to use many of them beyond perhaps an initial curiosity-motivated experimentation.
In a nutshell, this commit revamps the map/rank/bind procedure to take into account topology info on the compute nodes. I have, for the most part, preserved the default behaviors, with three notable exceptions:
1. I have at long last bowed my head in submission to the system admin's of managed clusters. For years, they have complained about our default of allowing users to oversubscribe nodes - i.e., to run more processes on a node than allocated slots. Accordingly, I have modified the default behavior: if you are running off of hostfile/dash-host allocated nodes, then the default is to allow oversubscription. If you are running off of RM-allocated nodes, then the default is to NOT allow oversubscription. Flags to override these behaviors are provided, so this only affects the default behavior.
2. both cpus/rank and stride have been removed. The latter was demanded by those who didn't understand the purpose behind it - and I agreed as the users who requested it are no longer using it. The former was removed temporarily pending implementation.
3. vm launch is now the sole method for starting OMPI. It was just too darned hard to maintain multiple launch procedures - maybe someday, provided someone can demonstrate a reason to do so.
As Jeff stated, it is impossible to fully test a change of this size. I have tested it on Linux and Mac, covering all the default and simple options, singletons, and comm_spawn. That said, I'm sure others will find problems, so I'll be watching MTT results until this stabilizes.
This commit was SVN r25476.
2011-11-15 07:40:11 +04:00
|
|
|
#if OPAL_HAVE_HWLOC
|
2012-10-30 23:45:18 +04:00
|
|
|
{ "orte_hetero_nodes", '\0', NULL, "hetero-nodes", 0,
|
2011-11-01 22:43:10 +04:00
|
|
|
NULL, OPAL_CMD_LINE_TYPE_BOOL,
|
|
|
|
|
"Nodes in cluster may differ in topology, so send the topology back from each node [Default = false]" },
|
At long last, the fabled revision to the affinity system has arrived. A more detailed explanation of how this all works will be presented here:
https://svn.open-mpi.org/trac/ompi/wiki/ProcessPlacement
The wiki page is incomplete at the moment, but I hope to complete it over the next few days. I will provide updates on the devel list. As the wiki page states, the default and most commonly used options remain unchanged (except as noted below). New, esoteric and complex options have been added, but unless you are a true masochist, you are unlikely to use many of them beyond perhaps an initial curiosity-motivated experimentation.
In a nutshell, this commit revamps the map/rank/bind procedure to take into account topology info on the compute nodes. I have, for the most part, preserved the default behaviors, with three notable exceptions:
1. I have at long last bowed my head in submission to the system admin's of managed clusters. For years, they have complained about our default of allowing users to oversubscribe nodes - i.e., to run more processes on a node than allocated slots. Accordingly, I have modified the default behavior: if you are running off of hostfile/dash-host allocated nodes, then the default is to allow oversubscription. If you are running off of RM-allocated nodes, then the default is to NOT allow oversubscription. Flags to override these behaviors are provided, so this only affects the default behavior.
2. both cpus/rank and stride have been removed. The latter was demanded by those who didn't understand the purpose behind it - and I agreed as the users who requested it are no longer using it. The former was removed temporarily pending implementation.
3. vm launch is now the sole method for starting OMPI. It was just too darned hard to maintain multiple launch procedures - maybe someday, provided someone can demonstrate a reason to do so.
As Jeff stated, it is impossible to fully test a change of this size. I have tested it on Linux and Mac, covering all the default and simple options, singletons, and comm_spawn. That said, I'm sure others will find problems, so I'll be watching MTT results until this stabilizes.
This commit was SVN r25476.
2011-11-15 07:40:11 +04:00
|
|
|
#endif
|
2011-11-01 22:43:10 +04:00
|
|
|
|
2012-10-30 23:45:18 +04:00
|
|
|
{ NULL, '\0', "mapreduce", "mapreduce", 0,
|
2012-05-03 01:00:22 +04:00
|
|
|
&orted_globals.mapreduce, OPAL_CMD_LINE_TYPE_BOOL,
|
|
|
|
|
"Whether to report process bindings to stderr" },
|
|
|
|
|
|
2007-07-12 23:53:18 +04:00
|
|
|
/* End of list */
|
2012-10-30 23:45:18 +04:00
|
|
|
{ NULL, '\0', NULL, NULL, 0,
|
2007-07-12 23:53:18 +04:00
|
|
|
NULL, OPAL_CMD_LINE_TYPE_NULL, NULL }
|
|
|
|
|
};
|
|
|
|
|
|
2011-11-26 06:33:05 +04:00
|
|
|
static void rml_cbfunc(int status,
|
|
|
|
|
struct orte_process_name_t* peer,
|
|
|
|
|
struct opal_buffer_t* buffer,
|
|
|
|
|
orte_rml_tag_t tag,
|
|
|
|
|
void* cbdata)
|
|
|
|
|
{
|
|
|
|
|
OBJ_RELEASE(buffer);
|
|
|
|
|
}
|
|
|
|
|
|
2007-07-12 23:53:18 +04:00
|
|
|
int orte_daemon(int argc, char *argv[])
|
|
|
|
|
{
|
|
|
|
|
int ret = 0;
|
|
|
|
|
opal_cmd_line_t *cmd_line = NULL;
|
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
|
|
|
|
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);
|
2011-07-07 22:54:30 +04:00
|
|
|
if (OPAL_SUCCESS != opal_cmd_line_create(cmd_line, orte_cmd_line_opts)) {
|
|
|
|
|
OBJ_RELEASE(cmd_line);
|
|
|
|
|
exit(1);
|
|
|
|
|
}
|
2007-07-12 23:53:18 +04:00
|
|
|
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);
|
2011-07-07 22:54:30 +04:00
|
|
|
fprintf(stderr, "Usage: %s [OPTION]...\n%s\n", argv[0], args);
|
2007-07-12 23:53:18 +04:00
|
|
|
free(args);
|
2011-07-07 22:54:30 +04:00
|
|
|
OBJ_RELEASE(cmd_line);
|
2007-07-12 23:53:18 +04:00
|
|
|
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);
|
|
|
|
|
|
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.
|
|
|
|
|
*/
|
2009-12-04 03:51:15 +03:00
|
|
|
if (OPAL_SUCCESS != opal_init_util(&argc, &argv)) {
|
2007-07-13 22:15:36 +04:00
|
|
|
fprintf(stderr, "OPAL failed to initialize -- orted aborting\n");
|
|
|
|
|
exit(1);
|
|
|
|
|
}
|
|
|
|
|
|
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);
|
|
|
|
|
|
2010-04-15 22:10:50 +04:00
|
|
|
/* purge any ess flag set in the environ when we were launched */
|
|
|
|
|
opal_unsetenv("OMPI_MCA_ess", &orte_launch_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) {
|
2011-11-30 03:24:52 +04:00
|
|
|
gethostname(hostname, 100);
|
2007-07-23 19:00:39 +04:00
|
|
|
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;
|
|
|
|
|
while (orted_spin_flag) {
|
|
|
|
|
i++;
|
|
|
|
|
if (1000 < i) i=0;
|
|
|
|
|
}
|
2008-03-23 15:33:04 +03:00
|
|
|
|
2010-03-13 02:57:50 +03:00
|
|
|
#if OPAL_ENABLE_FT_CR == 1
|
2007-10-17 17:47:36 +04:00
|
|
|
/* 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
|
|
|
|
2012-05-03 01:00:22 +04:00
|
|
|
/* if mapreduce set, flag it */
|
|
|
|
|
if (orted_globals.mapreduce) {
|
|
|
|
|
orte_map_reduce = true;
|
|
|
|
|
}
|
|
|
|
|
|
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.
|
|
|
|
|
*/
|
2009-05-04 15:07:40 +04:00
|
|
|
if (orted_globals.hnp) {
|
2009-12-04 03:51:15 +03:00
|
|
|
if (ORTE_SUCCESS != (ret = orte_init(&argc, &argv, ORTE_PROC_HNP))) {
|
2009-05-04 15:07:40 +04:00
|
|
|
ORTE_ERROR_LOG(ret);
|
|
|
|
|
return ret;
|
|
|
|
|
}
|
|
|
|
|
} else {
|
2009-12-04 03:51:15 +03:00
|
|
|
if (ORTE_SUCCESS != (ret = orte_init(&argc, &argv, ORTE_PROC_DAEMON))) {
|
2009-05-04 15:07:40 +04:00
|
|
|
ORTE_ERROR_LOG(ret);
|
|
|
|
|
return ret;
|
|
|
|
|
}
|
2007-07-12 23:53:18 +04:00
|
|
|
}
|
2011-07-12 21:07:41 +04:00
|
|
|
/* finalize the OPAL utils. As they are opened again from orte_init->opal_init
|
|
|
|
|
* we continue to have a reference count on them. So we have to finalize them twice...
|
|
|
|
|
*/
|
|
|
|
|
opal_finalize_util();
|
|
|
|
|
|
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) {
|
2012-04-06 18:23:13 +04:00
|
|
|
ORTE_TIMER_EVENT(orted_globals.fail_delay, 0, shutdown_callback, ORTE_SYS_PRI);
|
2008-06-03 01:46:34 +04:00
|
|
|
|
|
|
|
|
} else {
|
2009-03-06 00:50:47 +03:00
|
|
|
opal_output(0, "%s is executing clean %s", ORTE_NAME_PRINT(ORTE_PROC_MY_NAME),
|
2008-06-03 01:46:34 +04:00
|
|
|
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 */
|
2009-02-25 06:10:21 +03:00
|
|
|
ret = ORTE_ERROR_DEFAULT_EXIT_CODE;
|
|
|
|
|
goto DONE;
|
2008-06-03 01:46:34 +04:00
|
|
|
}
|
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
|
|
|
*/
|
2009-03-06 00:56:03 +03:00
|
|
|
orte_process_info.my_daemon_uri = orte_rml.get_contact_info();
|
2008-02-28 04:57:57 +03:00
|
|
|
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 */
|
2009-05-04 15:07:40 +04:00
|
|
|
if (ORTE_PROC_IS_HNP) {
|
2009-03-06 00:56:03 +03:00
|
|
|
orte_process_info.my_hnp_uri = orte_rml.get_contact_info();
|
2008-02-28 04:57:57 +03:00
|
|
|
ORTE_PROC_MY_HNP->jobid = ORTE_PROC_MY_NAME->jobid;
|
|
|
|
|
ORTE_PROC_MY_HNP->vpid = ORTE_PROC_MY_NAME->vpid;
|
|
|
|
|
}
|
|
|
|
|
|
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,
|
2012-04-06 18:23:13 +04:00
|
|
|
ORTE_RML_PERSISTENT, orte_daemon_recv, NULL);
|
2011-07-08 18:38:33 +04:00
|
|
|
if (ret != ORTE_SUCCESS && ret != ORTE_ERR_NOT_IMPLEMENTED) {
|
2007-07-12 23:53:18 +04:00
|
|
|
ORTE_ERROR_LOG(ret);
|
2009-02-25 06:10:21 +03:00
|
|
|
goto DONE;
|
2007-07-12 23:53:18 +04:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* 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",
|
2009-03-06 00:56:03 +03:00
|
|
|
ORTE_NAME_PRINT(ORTE_PROC_MY_NAME), (long)orte_process_info.pid,
|
|
|
|
|
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;
|
2012-04-06 18:23:13 +04:00
|
|
|
orte_node_t *node;
|
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;
|
2010-08-09 23:28:56 +04:00
|
|
|
char *tmp, *nptr, *sysinfo;
|
2012-06-27 18:53:55 +04:00
|
|
|
int32_t ljob;
|
2012-09-12 15:31:36 +04:00
|
|
|
orte_grpcomm_collective_t *coll;
|
|
|
|
|
orte_namelist_t *nm;
|
2008-02-28 04:57:57 +03:00
|
|
|
|
These changes were mostly captured in a prior RFC (except for #2 below) and are aimed specifically at improving startup performance and setting up the remaining modifications described in that RFC.
The commit has been tested for C/R and Cray operations, and on Odin (SLURM, rsh) and RoadRunner (TM). I tried to update all environments, but obviously could not test them. I know that Windows needs some work, and have highlighted what is know to be needed in the odls process component.
This represents a lot of work by Brian, Tim P, Josh, and myself, with much advice from Jeff and others. For posterity, I have appended a copy of the email describing the work that was done:
As we have repeatedly noted, the modex operation in MPI_Init is the single greatest consumer of time during startup. To-date, we have executed that operation as an ORTE stage gate that held the process until a startup message containing all required modex (and OOB contact info - see #3 below) info could be sent to it. Each process would send its data to the HNP's registry, which assembled and sent the message when all processes had reported in.
In addition, ORTE had taken responsibility for monitoring process status as it progressed through a series of "stage gates". The process reported its status at each gate, and ORTE would then send a "release" message once all procs had reported in.
The incoming changes revamp these procedures in three ways:
1. eliminating the ORTE stage gate system and cleanly delineating responsibility between the OMPI and ORTE layers for MPI init/finalize. The modex stage gate (STG1) has been replaced by a collective operation in the modex itself that performs an allgather on the required modex info. The allgather is implemented using the orte_grpcomm framework since the BTL's are not active at that point. At the moment, the grpcomm framework only has a "basic" component analogous to OMPI's "basic" coll framework - I would recommend that the MPI team create additional, more advanced components to improve performance of this step.
The other stage gates have been replaced by orte_grpcomm barrier functions. We tried to use MPI barriers instead (since the BTL's are active at that point), but - as we discussed on the telecon - these are not currently true barriers so the job would hang when we fell through while messages were still in process. Note that the grpcomm barrier doesn't actually resolve that problem, but Brian has pointed out that we are unlikely to ever see it violated. Again, you might want to spend a little time on an advanced barrier algorithm as the one in "basic" is very simplistic.
Summarizing this change: ORTE no longer tracks process state nor has direct responsibility for synchronizing jobs. This is now done via collective operations within the MPI layer, albeit using ORTE collective communication services. I -strongly- urge the MPI team to implement advanced collective algorithms to improve the performance of this critical procedure.
2. reducing the volume of data exchanged during modex. Data in the modex consisted of the process name, the name of the node where that process is located (expressed as a string), plus a string representation of all contact info. The nodename was required in order for the modex to determine if the process was local or not - in addition, some people like to have it to print pretty error messages when a connection failed.
The size of this data has been reduced in three ways:
(a) reducing the size of the process name itself. The process name consisted of two 32-bit fields for the jobid and vpid. This is far larger than any current system, or system likely to exist in the near future, can support. Accordingly, the default size of these fields has been reduced to 16-bits, which means you can have 32k procs in each of 32k jobs. Since the daemons must have a vpid, and we require one daemon/node, this also restricts the default configuration to 32k nodes.
To support any future "mega-clusters", a configuration option --enable-jumbo-apps has been added. This option increases the jobid and vpid field sizes to 32-bits. Someday, if necessary, someone can add yet another option to increase them to 64-bits, I suppose.
(b) replacing the string nodename with an integer nodeid. Since we have one daemon/node, the nodeid corresponds to the local daemon's vpid. This replaces an often lengthy string with only 2 (or at most 4) bytes, a substantial reduction.
(c) when the mca param requesting that nodenames be sent to support pretty error messages, a second mca param is now used to request FQDN - otherwise, the domain name is stripped (by default) from the message to save space. If someone wants to combine those into a single param somehow (perhaps with an argument?), they are welcome to do so - I didn't want to alter what people are already using.
While these may seem like small savings, they actually amount to a significant impact when aggregated across the entire modex operation. Since every proc must receive the modex data regardless of the collective used to send it, just reducing the size of the process name removes nearly 400MBytes of communication from a 32k proc job (admittedly, much of this comm may occur in parallel). So it does add up pretty quickly.
3. routing RML messages to reduce connections. The default messaging system remains point-to-point - i.e., each proc opens a socket to every proc it communicates with and sends its messages directly. A new option uses the orteds as routers - i.e., each proc only opens a single socket to its local orted. All messages are sent from the proc to the orted, which forwards the message to the orted on the node where the intended recipient proc is located - that orted then forwards the message to its local proc (the recipient). This greatly reduces the connection storm we have encountered during startup.
It also has the benefit of removing the sharing of every proc's OOB contact with every other proc. The orted routing tables are populated during launch since every orted gets a map of where every proc is being placed. Each proc, therefore, only needs to know the contact info for its local daemon, which is passed in via the environment when the proc is fork/exec'd by the daemon. This alone removes ~50 bytes/process of communication that was in the current STG1 startup message - so for our 32k proc job, this saves us roughly 32k*50 = 1.6MBytes sent to 32k procs = 51GBytes of messaging.
Note that you can use the new routing method by specifying -mca routed tree - if you so desire. This mode will become the default at some point in the future.
There are a few minor additional changes in the commit that I'll just note in passing:
* propagation of command line mca params to the orteds - fixes ticket #1073. See note there for details.
* requiring of "finalize" prior to "exit" for MPI procs - fixes ticket #1144. See note there for details.
* cleanup of some stale header files
This commit was SVN r16364.
2007-10-05 23:48:23 +04:00
|
|
|
/* setup the singleton's job */
|
2008-02-28 04:57:57 +03:00
|
|
|
jdata = OBJ_NEW(orte_job_t);
|
2009-06-06 05:08:47 +04:00
|
|
|
orte_plm_base_create_jobid(jdata);
|
|
|
|
|
ljob = ORTE_LOCAL_JOBID(jdata->jobid);
|
|
|
|
|
opal_pointer_array_set_item(orte_job_data, ljob, jdata);
|
2012-06-27 18:53:55 +04:00
|
|
|
|
2010-07-18 06:48:17 +04:00
|
|
|
/* must create a map for it (even though it has no
|
|
|
|
|
* info in it) so that the job info will be picked
|
|
|
|
|
* up in subsequent pidmaps or other daemons won't
|
|
|
|
|
* know how to route
|
|
|
|
|
*/
|
|
|
|
|
jdata->map = OBJ_NEW(orte_job_map_t);
|
|
|
|
|
|
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
|
|
|
/* 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;
|
2012-04-10 23:08:54 +04:00
|
|
|
proc->alive = true;
|
2008-02-28 04:57:57 +03:00
|
|
|
proc->state = ORTE_PROC_STATE_RUNNING;
|
|
|
|
|
proc->app_idx = 0;
|
2012-06-27 18:53:55 +04:00
|
|
|
/* obviously, it is on my node */
|
2012-04-06 18:23:13 +04:00
|
|
|
node = (orte_node_t*)opal_pointer_array_get_item(orte_node_pool, 0);
|
|
|
|
|
proc->node = node;
|
|
|
|
|
OBJ_RETAIN(node); /* 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;
|
2012-09-04 05:10:26 +04:00
|
|
|
/* and it obviously is on the node */
|
|
|
|
|
OBJ_RETAIN(proc);
|
|
|
|
|
opal_pointer_array_add(node->procs, proc);
|
|
|
|
|
node->num_procs++;
|
2012-06-27 18:53:55 +04:00
|
|
|
/* and obviously it is one of my local procs */
|
2012-04-10 23:08:54 +04:00
|
|
|
OBJ_RETAIN(proc);
|
|
|
|
|
opal_pointer_array_add(orte_local_children, proc);
|
2012-04-06 18:23:13 +04:00
|
|
|
jdata->num_local_procs = 1;
|
2012-06-27 18:53:55 +04:00
|
|
|
/* set the trivial */
|
|
|
|
|
proc->local_rank = 0;
|
|
|
|
|
proc->node_rank = 0;
|
|
|
|
|
proc->app_rank = 0;
|
|
|
|
|
proc->state = ORTE_PROC_STATE_RUNNING;
|
|
|
|
|
proc->alive = true;
|
|
|
|
|
proc->app_idx = 0;
|
|
|
|
|
proc->local_proc = true;
|
|
|
|
|
#if OPAL_HAVE_HWLOC
|
|
|
|
|
proc->bind_idx = 0;
|
|
|
|
|
#endif
|
|
|
|
|
|
2012-09-12 15:31:36 +04:00
|
|
|
/* create the collectives for its modex/barriers */
|
|
|
|
|
jdata->peer_modex = orte_grpcomm_base_get_coll_id();
|
|
|
|
|
coll = orte_grpcomm_base_setup_collective(jdata->peer_modex);
|
|
|
|
|
nm = OBJ_NEW(orte_namelist_t);
|
|
|
|
|
nm->name.jobid = jdata->jobid;
|
|
|
|
|
nm->name.vpid = ORTE_VPID_WILDCARD;
|
|
|
|
|
opal_list_append(&coll->participants, &nm->super);
|
|
|
|
|
|
|
|
|
|
jdata->peer_init_barrier = orte_grpcomm_base_get_coll_id();
|
|
|
|
|
coll = orte_grpcomm_base_setup_collective(jdata->peer_init_barrier);
|
|
|
|
|
nm = OBJ_NEW(orte_namelist_t);
|
|
|
|
|
nm->name.jobid = jdata->jobid;
|
|
|
|
|
nm->name.vpid = ORTE_VPID_WILDCARD;
|
|
|
|
|
opal_list_append(&coll->participants, &nm->super);
|
|
|
|
|
|
|
|
|
|
jdata->peer_fini_barrier = orte_grpcomm_base_get_coll_id();
|
|
|
|
|
coll = orte_grpcomm_base_setup_collective(jdata->peer_fini_barrier);
|
|
|
|
|
nm = OBJ_NEW(orte_namelist_t);
|
|
|
|
|
nm->name.jobid = jdata->jobid;
|
|
|
|
|
nm->name.vpid = ORTE_VPID_WILDCARD;
|
|
|
|
|
opal_list_append(&coll->participants, &nm->super);
|
2012-04-10 23:08:54 +04:00
|
|
|
|
2012-04-06 18:23:13 +04:00
|
|
|
/* need to setup a pidmap for it */
|
2012-08-29 01:20:17 +04:00
|
|
|
if (ORTE_SUCCESS != (ret = orte_util_encode_pidmap(&orte_pidmap, false))) {
|
2012-04-06 18:23:13 +04:00
|
|
|
ORTE_ERROR_LOG(ret);
|
2012-06-27 18:53:55 +04:00
|
|
|
goto DONE;
|
2012-04-06 18:23:13 +04:00
|
|
|
}
|
2012-06-27 18:53:55 +04:00
|
|
|
|
2012-04-06 18:23:13 +04:00
|
|
|
/* if we don't yet have a daemon map, then we have to generate one
|
|
|
|
|
* to pass back to it
|
|
|
|
|
*/
|
2012-08-31 05:07:36 +04:00
|
|
|
if (NULL != orte_nidmap.bytes) {
|
|
|
|
|
free(orte_nidmap.bytes);
|
|
|
|
|
}
|
2012-08-29 01:20:17 +04:00
|
|
|
if (ORTE_SUCCESS != (ret = orte_util_encode_nodemap(&orte_nidmap, false))) {
|
|
|
|
|
ORTE_ERROR_LOG(ret);
|
|
|
|
|
goto DONE;
|
2012-04-06 18:23:13 +04:00
|
|
|
}
|
|
|
|
|
|
2010-08-09 23:28:56 +04:00
|
|
|
/* create a string that contains our uri + the singleton's name + sysinfo */
|
2008-02-28 04:57:57 +03:00
|
|
|
orte_util_convert_process_name_to_string(&nptr, &proc->name);
|
2010-08-09 23:28:56 +04:00
|
|
|
orte_util_convert_sysinfo_to_string(&sysinfo, orte_local_cpu_type, orte_local_cpu_model);
|
|
|
|
|
asprintf(&tmp, "%s[%s][%s]", orte_process_info.my_daemon_uri, nptr, sysinfo);
|
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);
|
2010-08-09 23:28:56 +04:00
|
|
|
free(sysinfo);
|
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
|
|
|
|
|
|
|
|
/* pass that info to the singleton */
|
2010-04-10 20:30:59 +04:00
|
|
|
#ifndef __WINDOWS__
|
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
|
|
|
write(orted_globals.uri_pipe, tmp, strlen(tmp)+1); /* need to add 1 to get the NULL */
|
2010-04-10 20:30:59 +04:00
|
|
|
#else
|
|
|
|
|
send(orted_globals.uri_pipe, tmp, strlen(tmp)+1, 0); /* need to add 1 to get the NULL */
|
|
|
|
|
#endif
|
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
|
|
|
|
|
|
|
|
/* cleanup */
|
|
|
|
|
free(tmp);
|
2012-09-04 05:10:26 +04:00
|
|
|
|
|
|
|
|
/* since a singleton spawned us, we need to harvest
|
|
|
|
|
* any MCA params from the local environment so
|
|
|
|
|
* we can pass them along to any subsequent daemons
|
|
|
|
|
* we may start as the result of a comm_spawn
|
|
|
|
|
*/
|
|
|
|
|
for (i=0; NULL != environ[i]; i++) {
|
|
|
|
|
if (0 == strncmp(environ[i], "OMPI_MCA", 8)) {
|
|
|
|
|
/* make a copy to manipulate */
|
|
|
|
|
tmp = strdup(environ[i]);
|
|
|
|
|
/* find the equal sign */
|
|
|
|
|
nptr = strchr(tmp, '=');
|
|
|
|
|
*nptr = '\0';
|
|
|
|
|
nptr++;
|
|
|
|
|
/* add the mca param to the orted cmd line */
|
|
|
|
|
opal_argv_append_nosize(&orted_cmd_line, "-mca");
|
|
|
|
|
opal_argv_append_nosize(&orted_cmd_line, &tmp[9]);
|
|
|
|
|
opal_argv_append_nosize(&orted_cmd_line, nptr);
|
|
|
|
|
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 */
|
2012-04-06 18:23:13 +04:00
|
|
|
pipe_handler = (opal_event_t*)malloc(sizeof(opal_event_t));
|
|
|
|
|
opal_event_set(orte_event_base, pipe_handler,
|
2007-07-12 23:53:18 +04:00
|
|
|
orted_globals.singleton_died_pipe,
|
2012-04-06 18:23:13 +04:00
|
|
|
OPAL_EV_READ,
|
|
|
|
|
pipe_closed,
|
2012-04-10 23:08:54 +04:00
|
|
|
pipe_handler);
|
2012-04-06 18:23:13 +04:00
|
|
|
opal_event_add(pipe_handler, NULL);
|
2007-07-12 23:53:18 +04:00
|
|
|
}
|
|
|
|
|
|
2011-11-26 06:33:05 +04:00
|
|
|
/* If I have a parent, then save his contact info so
|
|
|
|
|
* any messages we send can flow thru him.
|
|
|
|
|
*/
|
|
|
|
|
mca_base_param_reg_string_name("orte", "parent_uri",
|
|
|
|
|
"URI for the parent if tree launch is enabled.",
|
|
|
|
|
true, false, NULL, &rml_uri);
|
|
|
|
|
if (NULL != rml_uri) {
|
|
|
|
|
orte_process_name_t parent;
|
|
|
|
|
|
|
|
|
|
/* set the contact info into the hash table */
|
|
|
|
|
if (ORTE_SUCCESS != (ret = orte_rml.set_contact_info(rml_uri))) {
|
|
|
|
|
ORTE_ERROR_LOG(ret);
|
|
|
|
|
free(rml_uri);
|
|
|
|
|
goto DONE;
|
|
|
|
|
}
|
|
|
|
|
ret = orte_rml_base_parse_uris(rml_uri, &parent, NULL );
|
|
|
|
|
if( ORTE_SUCCESS != ret ) {
|
|
|
|
|
ORTE_ERROR_LOG(ret);
|
|
|
|
|
free(rml_uri);
|
|
|
|
|
goto DONE;
|
|
|
|
|
}
|
|
|
|
|
free(rml_uri);
|
|
|
|
|
/* tell the routed module that we have a path
|
|
|
|
|
* back to the HNP
|
|
|
|
|
*/
|
|
|
|
|
if (ORTE_SUCCESS != (ret = orte_routed.update_route(ORTE_PROC_MY_HNP, &parent))) {
|
|
|
|
|
ORTE_ERROR_LOG(ret);
|
|
|
|
|
goto DONE;
|
|
|
|
|
}
|
2011-12-15 19:29:53 +04:00
|
|
|
/* set the lifeline to point to our parent so that we
|
|
|
|
|
* can handle the situation if that lifeline goes away
|
|
|
|
|
*/
|
|
|
|
|
if (ORTE_SUCCESS != (ret = orte_routed.set_lifeline(&parent))) {
|
|
|
|
|
ORTE_ERROR_LOG(ret);
|
|
|
|
|
goto DONE;
|
|
|
|
|
}
|
2011-11-26 06:33:05 +04:00
|
|
|
}
|
|
|
|
|
|
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
|
|
|
|
|
*/
|
2011-07-07 22:54:30 +04:00
|
|
|
if (!ORTE_PROC_IS_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);
|
2012-06-15 14:15:07 +04:00
|
|
|
/* insert our name for rollup purposes */
|
|
|
|
|
if (ORTE_SUCCESS != (ret = opal_dss.pack(buffer, ORTE_PROC_MY_NAME, 1, ORTE_NAME))) {
|
|
|
|
|
ORTE_ERROR_LOG(ret);
|
|
|
|
|
OBJ_RELEASE(buffer);
|
|
|
|
|
goto DONE;
|
|
|
|
|
}
|
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);
|
2009-02-25 06:10:21 +03:00
|
|
|
goto DONE;
|
2008-04-30 23:49:53 +04:00
|
|
|
}
|
Repair the tree spawn. The problem seems to come from the fact
that now the HNP send the messages using the routed component. In the case
of tree spawn, when a intermediary node spawn a child it doesn't know how
to forward a message to it, so when the node-map message is coming from
the HNP (as there is nothing yet in the contact/routing table) the message
is sent back the way it came. As a result the node-map message keeps jumping
between the HNP and the first level orteds.
The solution is to add a new option to the children orte_parent_uri, which
is only set when the orted is _not_ directly spawned by the HNP. When this
option is present on the argument list, the orted will add the parent to
its routing, and force the parent to update his routes (by sending the URI).
With this approach, the routing tree is build in same time as the processes
are spawned, and all messages from the HNP can be routed to the leaves.
However, this is far from an optimal solution. Right now, this so called tree
spawn, only spawn the children in a tree without doing anything about the
"connect back to the HNP" step. The HNP is flooded with reports from all the
orted. The total number of messages is higher than in the non tree startup
scheme, so we do not expect this approach to be scalable in the current
incarnation. A complete overhaul of the tree startup is required in order
improve the scalability. Stay tuned!
This commit was SVN r21504.
2009-06-24 02:10:25 +04:00
|
|
|
|
2011-11-26 06:33:05 +04:00
|
|
|
/* include our node name */
|
|
|
|
|
opal_dss.pack(buffer, &orte_process_info.nodename, 1, OPAL_STRING);
|
2013-01-18 09:00:05 +04:00
|
|
|
|
2012-11-16 08:04:29 +04:00
|
|
|
/* if requested, include any non-loopback aliases for this node */
|
|
|
|
|
if (orte_retain_aliases) {
|
|
|
|
|
char **aliases=NULL;
|
|
|
|
|
uint8_t naliases, ni;
|
2013-01-18 09:00:05 +04:00
|
|
|
char hostname[ORTE_MAX_HOSTNAME_SIZE];
|
|
|
|
|
char *ptr;
|
|
|
|
|
|
|
|
|
|
/* if we stripped the prefix, include full hostname as an alias */
|
|
|
|
|
if (orte_process_info.strip_prefix_from_node_names) {
|
|
|
|
|
gethostname(hostname, ORTE_MAX_HOSTNAME_SIZE);
|
|
|
|
|
/* if the hostname is an IP address, leave it alone */
|
|
|
|
|
if (!opal_net_isaddr(hostname) && !orte_keep_fqdn_hostnames) {
|
|
|
|
|
/* not an IP address, so remove any domain info */
|
|
|
|
|
if (NULL != (ptr = strchr(hostname, '.'))) {
|
|
|
|
|
*ptr = '\0';
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
opal_argv_append_nosize(&aliases, hostname);
|
|
|
|
|
}
|
2012-11-16 08:04:29 +04:00
|
|
|
opal_ifgetaliases(&aliases);
|
|
|
|
|
naliases = opal_argv_count(aliases);
|
|
|
|
|
if (ORTE_SUCCESS != (ret = opal_dss.pack(buffer, &naliases, 1, OPAL_UINT8))) {
|
|
|
|
|
ORTE_ERROR_LOG(ret);
|
|
|
|
|
OBJ_RELEASE(buffer);
|
|
|
|
|
goto DONE;
|
|
|
|
|
}
|
|
|
|
|
for (ni=0; ni < naliases; ni++) {
|
|
|
|
|
if (ORTE_SUCCESS != (ret = opal_dss.pack(buffer, &aliases[ni], 1, OPAL_STRING))) {
|
|
|
|
|
ORTE_ERROR_LOG(ret);
|
|
|
|
|
OBJ_RELEASE(buffer);
|
|
|
|
|
goto DONE;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
opal_argv_free(aliases);
|
|
|
|
|
}
|
|
|
|
|
|
2011-10-12 20:54:03 +04:00
|
|
|
#if OPAL_HAVE_HWLOC
|
2011-11-26 06:33:05 +04:00
|
|
|
/* add the local topology */
|
|
|
|
|
if (NULL != opal_hwloc_topology &&
|
|
|
|
|
(1 == ORTE_PROC_MY_NAME->vpid || orte_hetero_nodes)) {
|
|
|
|
|
if (ORTE_SUCCESS != (ret = opal_dss.pack(buffer, &opal_hwloc_topology, 1, OPAL_HWLOC_TOPO))) {
|
|
|
|
|
ORTE_ERROR_LOG(ret);
|
2009-12-01 02:11:25 +03:00
|
|
|
}
|
2011-11-26 06:33:05 +04:00
|
|
|
}
|
2011-09-11 23:02:24 +04:00
|
|
|
#endif
|
|
|
|
|
|
2012-06-22 01:29:28 +04:00
|
|
|
if ((orte_static_ports || orte_use_common_port) && !orted_globals.tree_spawn) {
|
2012-06-15 14:15:07 +04:00
|
|
|
/* use the rollup collective to send our data to the HNP
|
|
|
|
|
* so we minimize the HNP bottleneck
|
|
|
|
|
*/
|
|
|
|
|
orte_grpcomm_collective_t *coll;
|
|
|
|
|
coll = OBJ_NEW(orte_grpcomm_collective_t);
|
|
|
|
|
/* get the list of contributors we need from the routed module */
|
|
|
|
|
orte_routed.get_routing_list(ORTE_GRPCOMM_COLL_PEERS, coll);
|
|
|
|
|
/* add the collective to our list */
|
|
|
|
|
opal_list_append(&orte_grpcomm_base.active_colls, &coll->super);
|
|
|
|
|
/* send the buffer to ourselves to start the collective */
|
|
|
|
|
if (0 > (ret = orte_rml.send_buffer_nb(ORTE_PROC_MY_NAME, buffer,
|
|
|
|
|
ORTE_RML_TAG_ROLLUP, 0,
|
|
|
|
|
rml_cbfunc, NULL))) {
|
|
|
|
|
ORTE_ERROR_LOG(ret);
|
|
|
|
|
OBJ_RELEASE(buffer);
|
|
|
|
|
goto DONE;
|
|
|
|
|
}
|
|
|
|
|
} else {
|
|
|
|
|
/* send directly to the HNP's callback */
|
|
|
|
|
if (0 > (ret = orte_rml.send_buffer_nb(ORTE_PROC_MY_HNP, buffer,
|
|
|
|
|
ORTE_RML_TAG_ORTED_CALLBACK, 0,
|
|
|
|
|
rml_cbfunc, NULL))) {
|
|
|
|
|
ORTE_ERROR_LOG(ret);
|
|
|
|
|
OBJ_RELEASE(buffer);
|
|
|
|
|
goto DONE;
|
|
|
|
|
}
|
|
|
|
|
}
|
2007-07-12 23:53:18 +04:00
|
|
|
}
|
|
|
|
|
|
2012-08-23 01:41:50 +04:00
|
|
|
/* if we are tree-spawning, then we need to capture the MCA params
|
|
|
|
|
* from our cmd line so we can pass them along to the daemons we spawn -
|
|
|
|
|
* otherwise, only the first layer of daemons will ever see them
|
|
|
|
|
*/
|
|
|
|
|
if (orted_globals.tree_spawn) {
|
|
|
|
|
int j, k;
|
|
|
|
|
bool ignore;
|
|
|
|
|
char *no_keep[] = {
|
|
|
|
|
"orte_hnp_uri",
|
|
|
|
|
"orte_ess_jobid",
|
|
|
|
|
"orte_ess_vpid",
|
|
|
|
|
"orte_ess_num_procs",
|
|
|
|
|
"orte_parent_uri",
|
|
|
|
|
NULL
|
|
|
|
|
};
|
|
|
|
|
for (i=0; i < argc; i++) {
|
|
|
|
|
if (0 == strcmp("-mca", argv[i]) ||
|
|
|
|
|
0 == strcmp("--mca", argv[i]) ) {
|
|
|
|
|
ignore = false;
|
|
|
|
|
/* see if this is something we cannot pass along */
|
|
|
|
|
for (k=0; NULL != no_keep[k]; k++) {
|
|
|
|
|
if (0 == strcmp(no_keep[k], argv[i+1])) {
|
|
|
|
|
ignore = true;
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
if (!ignore) {
|
|
|
|
|
/* see if this is already present so we at least can
|
|
|
|
|
* avoid growing the cmd line with duplicates
|
|
|
|
|
*/
|
|
|
|
|
if (NULL != orted_cmd_line) {
|
|
|
|
|
for (j=0; NULL != orted_cmd_line[j]; j++) {
|
|
|
|
|
if (0 == strcmp(argv[i+1], orted_cmd_line[j])) {
|
|
|
|
|
/* already here - ignore it */
|
|
|
|
|
ignore = true;
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
if (!ignore) {
|
|
|
|
|
opal_argv_append_nosize(&orted_cmd_line, argv[i]);
|
|
|
|
|
opal_argv_append_nosize(&orted_cmd_line, argv[i+1]);
|
|
|
|
|
opal_argv_append_nosize(&orted_cmd_line, argv[i+2]);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
i += 2;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2007-07-12 23:53:18 +04:00
|
|
|
if (orte_debug_daemons_flag) {
|
2009-03-06 00:50:47 +03: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
|
|
|
}
|
|
|
|
|
|
2012-04-06 18:23:13 +04:00
|
|
|
/* loop the event lib until an exit event is detected */
|
2013-01-15 03:06:42 +04:00
|
|
|
#if ORTE_ENABLE_PROGRESS_THREADS
|
|
|
|
|
while (orte_event_base_active) {
|
|
|
|
|
/* provide a very short quiet period so we
|
|
|
|
|
* don't hammer the cpu while
|
|
|
|
|
*/
|
|
|
|
|
struct timespec tp = {0, 100};
|
|
|
|
|
nanosleep(&tp, NULL);
|
|
|
|
|
}
|
|
|
|
|
#else
|
|
|
|
|
while (orte_event_base_active) {
|
|
|
|
|
opal_event_loop(orte_event_base, OPAL_EVLOOP_ONCE);
|
|
|
|
|
}
|
|
|
|
|
#endif
|
2007-07-12 23:53:18 +04:00
|
|
|
|
2012-05-19 03:37:40 +04:00
|
|
|
/* ensure all local procs are dead */
|
|
|
|
|
orte_odls.kill_local_procs(NULL);
|
|
|
|
|
|
2011-07-07 22:54:30 +04:00
|
|
|
DONE:
|
2012-04-06 18:23:13 +04:00
|
|
|
/* update the exit status, in case it wasn't done */
|
|
|
|
|
ORTE_UPDATE_EXIT_STATUS(orte_exit_status);
|
|
|
|
|
|
|
|
|
|
/* cleanup and leave */
|
|
|
|
|
orte_finalize();
|
|
|
|
|
|
|
|
|
|
if (orte_debug_flag) {
|
|
|
|
|
fprintf(stderr, "exiting with status %d\n", orte_exit_status);
|
|
|
|
|
}
|
|
|
|
|
exit(orte_exit_status);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void pipe_closed(int fd, short flags, void *arg)
|
|
|
|
|
{
|
|
|
|
|
opal_event_t *ev = (opal_event_t*)arg;
|
|
|
|
|
|
|
|
|
|
/* no error here - we just want to terminate */
|
|
|
|
|
opal_event_free(ev);
|
|
|
|
|
ORTE_ACTIVATE_JOB_STATE(NULL, ORTE_JOB_STATE_DAEMONS_TERMINATED);
|
2008-02-28 04:57:57 +03:00
|
|
|
}
|
2007-07-12 23:53:18 +04:00
|
|
|
|
2008-02-28 04:57:57 +03:00
|
|
|
static void shutdown_callback(int fd, short flags, void *arg)
|
|
|
|
|
{
|
2012-04-06 18:23:13 +04:00
|
|
|
orte_timer_t *tm = (orte_timer_t*)arg;
|
|
|
|
|
|
|
|
|
|
if (NULL != tm) {
|
|
|
|
|
/* release the timer */
|
|
|
|
|
OBJ_RELEASE(tm);
|
2007-07-12 23:53:18 +04:00
|
|
|
}
|
2008-02-28 04:57:57 +03:00
|
|
|
|
2008-08-06 15:31:06 +04:00
|
|
|
/* if we were ordered to abort, do so */
|
|
|
|
|
if (orted_globals.abort) {
|
2009-03-06 00:50:47 +03:00
|
|
|
opal_output(0, "%s is executing clean abort", ORTE_NAME_PRINT(ORTE_PROC_MY_NAME));
|
2008-08-06 15:31:06 +04:00
|
|
|
/* do -not- call finalize as this will send a message to the HNP
|
2010-07-18 01:03:27 +04:00
|
|
|
* indicating clean termination! Instead, just kill our
|
|
|
|
|
* local procs, forcibly cleanup the local session_dir tree, and abort
|
2008-08-06 15:31:06 +04:00
|
|
|
*/
|
2010-07-18 01:03:27 +04:00
|
|
|
orte_odls.kill_local_procs(NULL);
|
2008-08-06 15:31:06 +04:00
|
|
|
orte_session_dir_cleanup(ORTE_JOBID_WILDCARD);
|
|
|
|
|
abort();
|
|
|
|
|
}
|
2012-04-06 18:23:13 +04:00
|
|
|
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_odls.kill_local_procs(NULL);
|
|
|
|
|
orte_session_dir_cleanup(ORTE_JOBID_WILDCARD);
|
|
|
|
|
exit(ORTE_ERROR_DEFAULT_EXIT_CODE);
|
2007-09-12 18:32:31 +04:00
|
|
|
}
|