2006-09-14 21:29:51 +00:00
|
|
|
/*
|
|
|
|
|
* Copyright (c) 2004-2005 The Trustees of Indiana University and Indiana
|
|
|
|
|
* University Research and Technology
|
|
|
|
|
* Corporation. All rights reserved.
|
|
|
|
|
* Copyright (c) 2004-2005 The University of Tennessee and The University
|
|
|
|
|
* of Tennessee Research Foundation. All rights
|
|
|
|
|
* reserved.
|
|
|
|
|
* Copyright (c) 2004-2005 High Performance Computing Center Stuttgart,
|
|
|
|
|
* University of Stuttgart. All rights reserved.
|
|
|
|
|
* Copyright (c) 2004-2005 The Regents of the University of California.
|
|
|
|
|
* All rights reserved.
|
|
|
|
|
* $COPYRIGHT$
|
|
|
|
|
*
|
|
|
|
|
* Additional copyrights may follow
|
|
|
|
|
*
|
|
|
|
|
* $HEADER$
|
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
#include "orte_config.h"
|
2008-02-28 01:57:57 +00:00
|
|
|
#include "orte/constants.h"
|
2006-09-14 21:29:51 +00:00
|
|
|
|
|
|
|
|
#include "opal/mca/mca.h"
|
|
|
|
|
#include "opal/mca/base/base.h"
|
|
|
|
|
#include "opal/mca/base/mca_base_param.h"
|
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-13 20:00:55 +00:00
|
|
|
#include "orte/util/output.h"
|
2006-09-14 21:29:51 +00:00
|
|
|
#include "opal/util/trace.h"
|
Squeeeeeeze the launch message. This is the message sent to the daemons that provides all the data required for launching their local procs. In reorganizing the ODLS framework, I discovered that we were sending a significant amount of unnecessary and repeated data. This commit resolves this by:
1. taking advantage of the fact that we no longer create the launch message via a GPR trigger. In earlier times, we had the GPR create the launch message based on a subscription. In that mode of operation, we could not guarantee the order in which the data was stored in the message - hence, we had no choice but to parse the message in a loop that checked each value against a list of possible "keys" until the corresponding value was found.
Now, however, we construct the message "by hand", so we know precisely what data is in each location in the message. Thus, we no longer need to send the character string "keys" for each data value any more. This represents a rather large savings in the message size - to give you an example, we typically would use a 30-char "key" for a 2-byte data value. As you can see, the overhead can become very large.
2. sending node-specific data only once. Again, because we used to construct the message via subscriptions that were done on a per-proc basis, the data for each node (e.g., the daemon's name, whether or not the node was oversubscribed) would be included in the data for each proc. Thus, the node-specific data was repeated for every proc.
Now that we construct the message "by hand", there is no reason to do this any more. Instead, we can insert the data for a specific node only once, and then provide the per-proc data for that node. We therefore not only save all that extra data in the message, but we also only need to parse the per-node data once.
The savings become significant at scale. Here is a comparison between the revised trunk and the trunk prior to this commit (all data was taken on odin, using openib, 64 nodes, unity message routing, tested with application consisting of mpi_init/mpi_barrier/mpi_finalize, all execution times given in seconds, all launch message sizes in bytes):
Per-node scaling, taken at 1ppn:
#nodes original trunk revised trunk
time size time size
1 0.10 819 0.09 564
2 0.14 1070 0.14 677
3 0.15 1321 0.14 790
4 0.15 1572 0.15 903
8 0.17 2576 0.20 1355
16 0.25 4584 0.21 2259
32 0.28 8600 0.27 4067
64 0.50 16632 0.39 7683
Per-proc scaling, taken at 64 nodes
ppn original trunk revised trunk
time size time size
1 0.50 16669 0.40 7720
2 0.55 32733 0.54 11048
3 0.87 48797 0.81 14376
4 1.0 64861 0.85 17704
Condensing those numbers, it appears we gained:
per-node message size: 251 bytes/node -> 113 bytes/node
per-proc message size: 251 bytes/proc -> 52 bytes/proc
per-job message size: 568 bytes/job -> 399 bytes/job
(job-specific data such as jobid, override oversubscribe flag, total #procs in job, total slots allocated)
The fact that the two pre-commit trunk numbers are the same confirms the fact that each proc was containing the node data as well. It isn't quite the 10x message reduction I had hoped to get, but it is significant and gives much better scaling.
Note that the timing info was, as usual, pretty chaotic - the numbers cited here were typical across several runs taken after the initial one to avoid NFS file positioning influences.
Also note that this commit removes the orte_process_info.vpid_start field and the handful of places that passed that useless value. By definition, all jobs start at vpid=0, so all we were doing is passing "0" around. In fact, many places simply hardwired it to "0" anyway rather than deal with it.
This commit was SVN r16428.
2007-10-11 15:57:26 +00:00
|
|
|
#include "opal/util/argv.h"
|
2008-04-09 22:10:53 +00:00
|
|
|
#include "opal/class/opal_value_array.h"
|
2008-04-14 18:26:08 +00:00
|
|
|
#include "opal/class/opal_pointer_array.h"
|
2008-02-28 01:57:57 +00:00
|
|
|
#include "opal/dss/dss.h"
|
2008-04-09 22:10:53 +00:00
|
|
|
|
2006-09-14 21:29:51 +00:00
|
|
|
#include "orte/mca/errmgr/errmgr.h"
|
2008-02-28 01:57:57 +00:00
|
|
|
#include "orte/mca/plm/plm_types.h"
|
|
|
|
|
#include "orte/util/name_fns.h"
|
|
|
|
|
#include "orte/runtime/orte_globals.h"
|
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-13 20:00:55 +00:00
|
|
|
#include "orte/util/output.h"
|
2006-09-14 21:29:51 +00:00
|
|
|
|
|
|
|
|
#include "orte/mca/odls/base/base.h"
|
|
|
|
|
#include "orte/mca/odls/base/odls_private.h"
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* The following file was created by configure. It contains extern
|
|
|
|
|
* statements and the definition of an array of pointers to each
|
|
|
|
|
* component's public mca_base_component_t struct.
|
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
#include "orte/mca/odls/base/static-components.h"
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Instantiate globals
|
|
|
|
|
*/
|
|
|
|
|
orte_odls_base_module_t orte_odls;
|
|
|
|
|
|
2006-11-11 04:03:45 +00:00
|
|
|
/* instance the child list object */
|
|
|
|
|
static void orte_odls_child_constructor(orte_odls_child_t *ptr)
|
|
|
|
|
{
|
|
|
|
|
ptr->name = NULL;
|
Compute and pass the local_rank and local number of procs (in that proc's job) on the node.
To be precise, given this hypothetical launching pattern:
host1: vpids 0, 2, 4, 6
host2: vpids 1, 3, 5, 7
The local_rank for these procs would be:
host1: vpids 0->local_rank 0, v2->lr1, v4->lr2, v6->lr3
host2: vpids 1->local_rank 0, v3->lr1, v5->lr2, v7->lr3
and the number of local procs on each node would be four. If vpid=0 then does a comm_spawn of one process on host1, the values of the parent job would remain unchanged. The local_rank of the child process would be 0 and its num_local_procs would be 1 since it is in a separate jobid.
I have verified this functionality for the rsh case - need to verify that slurm and other cases also get the right values. Some consolidation of common code is probably going to occur in the SDS components to make this simpler and more maintainable in the future.
This commit was SVN r14706.
2007-05-21 14:30:10 +00:00
|
|
|
ptr->local_rank = ORTE_VPID_INVALID;
|
2006-11-11 04:03:45 +00:00
|
|
|
ptr->pid = 0;
|
|
|
|
|
ptr->app_idx = -1;
|
|
|
|
|
ptr->alive = false;
|
2008-03-27 15:17:53 +00:00
|
|
|
ptr->coll_recvd = false;
|
2008-02-28 01:57:57 +00:00
|
|
|
/* set the default state to "failed to start" so
|
|
|
|
|
* we can correctly report should something
|
|
|
|
|
* go wrong during launch
|
|
|
|
|
*/
|
|
|
|
|
ptr->state = ORTE_PROC_STATE_FAILED_TO_START;
|
2007-04-24 18:54:45 +00:00
|
|
|
ptr->exit_code = 0;
|
2008-02-28 01:57:57 +00:00
|
|
|
ptr->rml_uri = NULL;
|
2008-03-18 09:39:07 +00:00
|
|
|
ptr->slot_list = NULL;
|
2006-11-11 04:03:45 +00:00
|
|
|
}
|
|
|
|
|
static void orte_odls_child_destructor(orte_odls_child_t *ptr)
|
|
|
|
|
{
|
|
|
|
|
if (NULL != ptr->name) free(ptr->name);
|
2008-02-28 01:57:57 +00:00
|
|
|
if (NULL != ptr->rml_uri) free(ptr->rml_uri);
|
2008-03-18 09:39:07 +00:00
|
|
|
if (NULL != ptr->slot_list) free(ptr->slot_list);
|
2006-11-11 04:03:45 +00:00
|
|
|
}
|
|
|
|
|
OBJ_CLASS_INSTANCE(orte_odls_child_t,
|
|
|
|
|
opal_list_item_t,
|
|
|
|
|
orte_odls_child_constructor,
|
|
|
|
|
orte_odls_child_destructor);
|
|
|
|
|
|
2008-04-09 22:10:53 +00:00
|
|
|
static void orte_odls_job_constructor(orte_odls_job_t *ptr)
|
|
|
|
|
{
|
|
|
|
|
ptr->jobid = ORTE_JOBID_INVALID;
|
2008-04-30 19:49:53 +00:00
|
|
|
ptr->apps = NULL;
|
|
|
|
|
ptr->num_apps = 0;
|
|
|
|
|
ptr->total_slots_alloc = 0;
|
|
|
|
|
ptr->num_procs = 0;
|
|
|
|
|
ptr->num_local_procs = 0;
|
|
|
|
|
ptr->procmap = NULL;
|
|
|
|
|
ptr->pmap = NULL;
|
2008-05-06 20:16:17 +00:00
|
|
|
OBJ_CONSTRUCT(&ptr->collection_bucket, opal_buffer_t);
|
|
|
|
|
OBJ_CONSTRUCT(&ptr->local_collection, opal_buffer_t);
|
2008-05-02 12:00:08 +00:00
|
|
|
ptr->collective_type = ORTE_GRPCOMM_COLL_NONE;
|
2008-05-06 20:16:17 +00:00
|
|
|
ptr->num_contributors = 0;
|
|
|
|
|
ptr->num_participating = 0;
|
|
|
|
|
ptr->num_collected = 0;
|
2008-04-09 22:10:53 +00:00
|
|
|
}
|
|
|
|
|
static void orte_odls_job_destructor(orte_odls_job_t *ptr)
|
|
|
|
|
{
|
2008-04-30 19:49:53 +00:00
|
|
|
orte_std_cntr_t i;
|
|
|
|
|
|
|
|
|
|
if (NULL != ptr->apps) {
|
|
|
|
|
for (i=0; i < ptr->num_apps; i++) {
|
|
|
|
|
OBJ_RELEASE(ptr->apps[i]);
|
|
|
|
|
}
|
|
|
|
|
if (NULL != ptr->apps) {
|
|
|
|
|
free(ptr->apps);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (NULL != ptr->procmap) {
|
|
|
|
|
free(ptr->procmap);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (NULL != ptr->pmap && NULL != ptr->pmap->bytes) {
|
|
|
|
|
free(ptr->pmap->bytes);
|
|
|
|
|
free(ptr->pmap);
|
|
|
|
|
}
|
2008-05-02 12:00:08 +00:00
|
|
|
|
2008-05-06 20:16:17 +00:00
|
|
|
OBJ_DESTRUCT(&ptr->collection_bucket);
|
|
|
|
|
OBJ_DESTRUCT(&ptr->local_collection);
|
2008-04-09 22:10:53 +00:00
|
|
|
}
|
|
|
|
|
OBJ_CLASS_INSTANCE(orte_odls_job_t,
|
|
|
|
|
opal_list_item_t,
|
|
|
|
|
orte_odls_job_constructor,
|
|
|
|
|
orte_odls_job_destructor);
|
|
|
|
|
|
2006-09-14 21:29:51 +00:00
|
|
|
/*
|
|
|
|
|
* Framework global variables
|
|
|
|
|
*/
|
|
|
|
|
orte_odls_base_t orte_odls_base;
|
|
|
|
|
orte_odls_globals_t orte_odls_globals;
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* Function for finding and opening either all MCA components, or the one
|
|
|
|
|
* that was specifically requested via a MCA parameter.
|
|
|
|
|
*/
|
|
|
|
|
int orte_odls_base_open(void)
|
|
|
|
|
{
|
2008-02-28 01:57:57 +00:00
|
|
|
/* Debugging / verbose output. Always have stream open, with
|
|
|
|
|
verbose set by the mca open system... */
|
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-13 20:00:55 +00:00
|
|
|
orte_odls_globals.output = orte_output_open(NULL, "ODLS", "DEBUG", NULL);
|
2006-09-14 21:29:51 +00:00
|
|
|
|
2007-08-18 03:05:45 +00:00
|
|
|
mca_base_param_reg_int_name("odls", "base_sigkill_timeout",
|
2006-11-17 02:58:46 +00:00
|
|
|
"Time to wait for a process to die after issuing a kill signal to it",
|
|
|
|
|
false, false, 1, &orte_odls_globals.timeout_before_sigkill);
|
Bring in the code for routing xcast stage gate messages via the local orteds. This code is inactive unless you specifically request it via an mca param oob_xcast_mode (can be set to "linear" or "direct"). Direct mode is the old standard method where we send messages directly to each MPI process. Linear mode sends the xcast message via the orteds, with the HNP sending the message to each orted directly.
There is a binomial algorithm in the code (i.e., the HNP would send to a subset of the orteds, which then relay it on according to the typical log-2 algo), but that has a bug in it so the code won't let you select it even if you tried (and the mca param doesn't show, so you'd *really* have to try).
This also involved a slight change to the oob.xcast API, so propagated that as required.
Note: this has *only* been tested on rsh, SLURM, and Bproc environments (now that it has been transferred to the OMPI trunk, I'll need to re-test it [only done rsh so far]). It should work fine on any environment that uses the ORTE daemons - anywhere else, you are on your own... :-)
Also, correct a mistake where the orte_debug_flag was declared an int, but the mca param was set as a bool. Move the storage for that flag to the orte/runtime/params.c and orte/runtime/params.h files appropriately.
This commit was SVN r14475.
2007-04-23 18:41:04 +00:00
|
|
|
|
2007-10-10 15:02:10 +00:00
|
|
|
/* initialize globals */
|
|
|
|
|
OBJ_CONSTRUCT(&orte_odls_globals.mutex, opal_mutex_t);
|
|
|
|
|
OBJ_CONSTRUCT(&orte_odls_globals.cond, opal_condition_t);
|
|
|
|
|
OBJ_CONSTRUCT(&orte_odls_globals.children, opal_list_t);
|
2008-04-09 22:10:53 +00:00
|
|
|
OBJ_CONSTRUCT(&orte_odls_globals.jobs, opal_list_t);
|
2008-04-30 19:49:53 +00:00
|
|
|
orte_odls_globals.dmap = NULL;
|
|
|
|
|
|
2008-04-14 18:26:08 +00:00
|
|
|
/* initialize and setup the daemonmap */
|
|
|
|
|
OBJ_CONSTRUCT(&orte_daemonmap, opal_pointer_array_t);
|
|
|
|
|
opal_pointer_array_init(&orte_daemonmap, 8, INT32_MAX, 8);
|
|
|
|
|
|
2006-09-14 21:29:51 +00:00
|
|
|
/* Open up all available components */
|
|
|
|
|
|
|
|
|
|
if (ORTE_SUCCESS !=
|
|
|
|
|
mca_base_components_open("odls", orte_odls_globals.output,
|
|
|
|
|
mca_odls_base_static_components,
|
|
|
|
|
&orte_odls_base.available_components, true)) {
|
|
|
|
|
return ORTE_ERROR;
|
|
|
|
|
}
|
2007-01-27 15:37:13 +00:00
|
|
|
|
|
|
|
|
/* are there components available for use ? -
|
|
|
|
|
* orte_odls_base.available_components is always initialized */
|
|
|
|
|
if(0 < opal_list_get_size(&(orte_odls_base.available_components))) {
|
|
|
|
|
orte_odls_base.components_available = true;
|
|
|
|
|
} else {
|
|
|
|
|
orte_odls_base.components_available = false;
|
|
|
|
|
}
|
2006-09-14 21:29:51 +00:00
|
|
|
|
|
|
|
|
/* All done */
|
|
|
|
|
|
|
|
|
|
return ORTE_SUCCESS;
|
|
|
|
|
}
|