2005-10-07 22:24:52 +00:00
|
|
|
/*
|
2005-11-05 19:57:48 +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.
|
2015-06-23 20:59:57 -07:00
|
|
|
* Copyright (c) 2004-2005 High Performance Computing Center Stuttgart,
|
2005-10-07 22:24:52 +00:00
|
|
|
* University of Stuttgart. All rights reserved.
|
|
|
|
* Copyright (c) 2004-2005 The Regents of the University of California.
|
|
|
|
* All rights reserved.
|
2012-08-03 16:30:05 +00:00
|
|
|
* Copyright (c) 2011-2012 Los Alamos National Security, LLC. All rights
|
2015-06-23 20:59:57 -07:00
|
|
|
* reserved.
|
2015-03-16 16:25:01 -07:00
|
|
|
* Copyright (c) 2014-2015 Intel, Inc. All rights reserved.
|
2005-10-07 22:24:52 +00:00
|
|
|
* $COPYRIGHT$
|
2015-06-23 20:59:57 -07:00
|
|
|
*
|
2005-10-07 22:24:52 +00:00
|
|
|
* Additional copyrights may follow
|
2015-06-23 20:59:57 -07:00
|
|
|
*
|
2005-10-07 22:24:52 +00:00
|
|
|
* $HEADER$
|
|
|
|
*/
|
|
|
|
|
|
|
|
#include "orte_config.h"
|
2009-03-13 02:10:32 +00:00
|
|
|
|
|
|
|
#include <string.h>
|
|
|
|
|
2008-02-28 01:57:57 +00:00
|
|
|
#include "orte/constants.h"
|
|
|
|
#include "orte/types.h"
|
2005-10-07 22:24:52 +00:00
|
|
|
|
2015-03-05 20:50:44 -07:00
|
|
|
#include "orte/mca/mca.h"
|
2005-10-07 22:24:52 +00:00
|
|
|
#include "opal/mca/base/base.h"
|
2006-10-17 16:06:17 +00:00
|
|
|
#include "opal/class/opal_list.h"
|
2009-02-14 02:26:12 +00:00
|
|
|
#include "opal/util/output.h"
|
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 03:40:11 +00:00
|
|
|
#include "opal/dss/dss.h"
|
2012-10-18 00:40:44 +00:00
|
|
|
#include "opal/util/argv.h"
|
2015-03-16 16:25:01 -07:00
|
|
|
#include "opal/mca/if/if.h"
|
2006-10-17 16:06:17 +00:00
|
|
|
|
2008-06-09 14:53:58 +00:00
|
|
|
#include "orte/util/show_help.h"
|
2005-10-07 22:24:52 +00:00
|
|
|
#include "orte/mca/errmgr/errmgr.h"
|
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 03:40:11 +00:00
|
|
|
#include "orte/mca/rmaps/base/base.h"
|
2008-02-28 01:57:57 +00:00
|
|
|
#include "orte/util/name_fns.h"
|
|
|
|
#include "orte/runtime/orte_globals.h"
|
2008-08-05 15:09:29 +00:00
|
|
|
#include "orte/runtime/orte_wait.h"
|
2008-02-28 01:57:57 +00:00
|
|
|
#include "orte/util/hostfile/hostfile.h"
|
|
|
|
#include "orte/util/dash_host/dash_host.h"
|
2008-03-23 23:10:15 +00:00
|
|
|
#include "orte/util/proc_info.h"
|
2009-09-09 17:47:58 +00:00
|
|
|
#include "orte/util/comm/comm.h"
|
2014-04-30 22:26:18 +00:00
|
|
|
#include "orte/util/error_strings.h"
|
2012-04-06 14:23:13 +00:00
|
|
|
#include "orte/mca/state/state.h"
|
2010-07-17 21:03:27 +00:00
|
|
|
#include "orte/runtime/orte_quit.h"
|
2005-10-07 22:24:52 +00:00
|
|
|
|
2006-09-14 21:29:51 +00:00
|
|
|
#include "orte/mca/ras/base/ras_private.h"
|
2005-10-07 22:24:52 +00:00
|
|
|
|
If (and only if) a user requests, set the default number of slots on any node to the number of objects of the specified type. This *only* takes effect in an unmanaged environment - i.e., if an external resource manager assigns us a number of slots, then that is what we use. However, if we are using a hostfile, then the user may or may not have given us a value for the number of slots on each node.
For those nodes (and *only* those nodes) where the user does *not* specify a slot count, we will set the number of slots according to their direction: either to the number of cores, numas, sockets, or hwthreads. Otherwise, the slot count is set to 1.
Note that the default behavior remains unchanged: in the absence of any value for #slots, and in the absence of any directive to set #slots, we will set #slots=1.
This commit was SVN r27236.
2012-09-04 20:58:26 +00:00
|
|
|
/* function to display allocation */
|
|
|
|
void orte_ras_base_display_alloc(void)
|
2009-07-14 14:34:11 +00:00
|
|
|
{
|
2013-12-21 01:38:27 +00:00
|
|
|
char *tmp=NULL, *tmp2, *tmp3;
|
2012-09-04 11:50:52 +00:00
|
|
|
int i, istart;
|
2009-07-14 14:34:11 +00:00
|
|
|
orte_node_t *alloc;
|
2015-06-23 20:59:57 -07:00
|
|
|
|
2009-07-14 14:34:11 +00:00
|
|
|
if (orte_xml_output) {
|
|
|
|
asprintf(&tmp, "<allocation>\n");
|
|
|
|
} else {
|
|
|
|
asprintf(&tmp, "\n====================== ALLOCATED NODES ======================\n");
|
|
|
|
}
|
2012-09-04 11:50:52 +00:00
|
|
|
if (orte_hnp_is_allocated) {
|
|
|
|
istart = 0;
|
|
|
|
} else {
|
|
|
|
istart = 1;
|
|
|
|
}
|
|
|
|
for (i=istart; i < orte_node_pool->size; i++) {
|
2009-07-14 14:34:11 +00:00
|
|
|
if (NULL == (alloc = (orte_node_t*)opal_pointer_array_get_item(orte_node_pool, i))) {
|
|
|
|
continue;
|
|
|
|
}
|
2013-12-21 01:38:27 +00:00
|
|
|
if (orte_xml_output) {
|
|
|
|
/* need to create the output in XML format */
|
|
|
|
asprintf(&tmp2, "\t<host name=\"%s\" slots=\"%d\" max_slots=\"%d\" slots_inuse=\"%d\">\n",
|
|
|
|
(NULL == alloc->name) ? "UNKNOWN" : alloc->name,
|
|
|
|
(int)alloc->slots, (int)alloc->slots_max, (int)alloc->slots_inuse);
|
|
|
|
} else {
|
2014-04-30 22:26:18 +00:00
|
|
|
asprintf(&tmp2, "\t%s: slots=%d max_slots=%d slots_inuse=%d state=%s\n",
|
2013-12-21 01:38:27 +00:00
|
|
|
(NULL == alloc->name) ? "UNKNOWN" : alloc->name,
|
2014-04-30 22:26:18 +00:00
|
|
|
(int)alloc->slots, (int)alloc->slots_max, (int)alloc->slots_inuse,
|
|
|
|
orte_node_state_to_str(alloc->state));
|
2013-12-21 01:38:27 +00:00
|
|
|
}
|
2009-07-14 14:34:11 +00:00
|
|
|
if (NULL == tmp) {
|
|
|
|
tmp = tmp2;
|
|
|
|
} else {
|
|
|
|
asprintf(&tmp3, "%s%s", tmp, tmp2);
|
|
|
|
free(tmp);
|
|
|
|
free(tmp2);
|
|
|
|
tmp = tmp3;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
if (orte_xml_output) {
|
2009-09-02 18:03:10 +00:00
|
|
|
fprintf(orte_xml_fp, "%s</allocation>\n", tmp);
|
|
|
|
fflush(orte_xml_fp);
|
2009-07-14 14:34:11 +00:00
|
|
|
} else {
|
2013-12-21 01:38:27 +00:00
|
|
|
opal_output(orte_clean_output, "%s=================================================================\n", tmp);
|
2009-07-14 14:34:11 +00:00
|
|
|
}
|
2015-06-23 20:59:57 -07:00
|
|
|
free(tmp);
|
2009-07-14 14:34:11 +00:00
|
|
|
}
|
|
|
|
|
2005-10-07 22:24:52 +00:00
|
|
|
/*
|
|
|
|
* Function for selecting one component from all those that are
|
|
|
|
* available.
|
|
|
|
*/
|
2012-04-06 14:23:13 +00:00
|
|
|
void orte_ras_base_allocate(int fd, short args, void *cbdata)
|
2005-10-07 22:24:52 +00:00
|
|
|
{
|
2008-02-28 01:57:57 +00:00
|
|
|
int rc;
|
2012-04-06 14:23:13 +00:00
|
|
|
orte_job_t *jdata;
|
2006-10-19 23:33:51 +00:00
|
|
|
opal_list_t nodes;
|
2009-07-14 14:34:11 +00:00
|
|
|
orte_node_t *node;
|
2008-02-28 01:57:57 +00:00
|
|
|
orte_std_cntr_t i;
|
2009-07-14 14:34:11 +00:00
|
|
|
orte_app_context_t *app;
|
2012-04-06 14:23:13 +00:00
|
|
|
orte_state_caddy_t *caddy = (orte_state_caddy_t*)cbdata;
|
2014-06-01 16:14:10 +00:00
|
|
|
char *hosts;
|
2008-02-28 01:57:57 +00:00
|
|
|
|
2013-03-27 21:14:43 +00:00
|
|
|
OPAL_OUTPUT_VERBOSE((5, orte_ras_base_framework.framework_output,
|
2008-02-28 01:57:57 +00:00
|
|
|
"%s ras:base:allocate",
|
2009-03-05 21:50:47 +00:00
|
|
|
ORTE_NAME_PRINT(ORTE_PROC_MY_NAME)));
|
2015-06-23 20:59:57 -07:00
|
|
|
|
2012-04-06 14:23:13 +00:00
|
|
|
/* convenience */
|
|
|
|
jdata = caddy->jdata;
|
|
|
|
|
2008-02-28 01:57:57 +00:00
|
|
|
/* if we already did this, don't do it again - the pool of
|
2015-06-23 20:59:57 -07:00
|
|
|
* global resources is set.
|
2008-02-28 01:57:57 +00:00
|
|
|
*/
|
|
|
|
if (orte_ras_base.allocation_read) {
|
2015-06-23 20:59:57 -07:00
|
|
|
|
2013-03-27 21:14:43 +00:00
|
|
|
OPAL_OUTPUT_VERBOSE((5, orte_ras_base_framework.framework_output,
|
2008-02-28 01:57:57 +00:00
|
|
|
"%s ras:base:allocate allocation already read",
|
2009-03-05 21:50:47 +00:00
|
|
|
ORTE_NAME_PRINT(ORTE_PROC_MY_NAME)));
|
2012-04-06 14:23:13 +00:00
|
|
|
goto next_state;
|
2006-10-19 23:33:51 +00:00
|
|
|
}
|
2012-04-06 14:23:13 +00:00
|
|
|
orte_ras_base.allocation_read = true;
|
|
|
|
|
2008-02-28 01:57:57 +00:00
|
|
|
/* Otherwise, we have to create
|
|
|
|
* the initial set of resources that will delineate all
|
|
|
|
* further operations serviced by this HNP. This list will
|
|
|
|
* contain ALL nodes that can be used by any subsequent job.
|
|
|
|
*
|
|
|
|
* In other words, if a node isn't found in this step, then
|
|
|
|
* no job launched by this HNP will be able to utilize it.
|
|
|
|
*/
|
2015-06-23 20:59:57 -07:00
|
|
|
|
2008-02-28 01:57:57 +00:00
|
|
|
/* construct a list to hold the results */
|
|
|
|
OBJ_CONSTRUCT(&nodes, opal_list_t);
|
|
|
|
|
|
|
|
/* if a component was selected, then we know we are in a managed
|
|
|
|
* environment. - the active module will return a list of what it found
|
|
|
|
*/
|
|
|
|
if (NULL != orte_ras_base.active_module) {
|
|
|
|
/* read the allocation */
|
2012-11-23 13:50:10 +00:00
|
|
|
if (ORTE_SUCCESS != (rc = orte_ras_base.active_module->allocate(jdata, &nodes))) {
|
2013-01-20 00:33:42 +00:00
|
|
|
if (ORTE_ERR_ALLOCATION_PENDING == rc) {
|
|
|
|
/* an allocation request is underway, so just do nothing */
|
|
|
|
OBJ_DESTRUCT(&nodes);
|
|
|
|
OBJ_RELEASE(caddy);
|
|
|
|
return;
|
|
|
|
}
|
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 03:40:11 +00:00
|
|
|
if (ORTE_ERR_SYSTEM_WILL_BOOTSTRAP == rc) {
|
2009-09-30 23:30:24 +00:00
|
|
|
/* this module indicates that nodes will be discovered
|
2009-10-14 17:43:40 +00:00
|
|
|
* on a bootstrap basis, so all we do here is add our
|
|
|
|
* own node to the list
|
2009-09-30 23:30:24 +00:00
|
|
|
*/
|
2009-10-14 17:43:40 +00:00
|
|
|
goto addlocal;
|
2009-09-30 23:30:24 +00:00
|
|
|
}
|
2013-01-20 00:33:42 +00:00
|
|
|
if (ORTE_ERR_TAKE_NEXT_OPTION == rc) {
|
|
|
|
/* we have an active module, but it is unable to
|
|
|
|
* allocate anything for this job - this indicates
|
|
|
|
* that it isn't a fatal error, but could be if
|
|
|
|
* an allocation is required
|
|
|
|
*/
|
|
|
|
if (orte_allocation_required) {
|
|
|
|
/* an allocation is required, so this is fatal */
|
|
|
|
OBJ_DESTRUCT(&nodes);
|
|
|
|
orte_show_help("help-ras-base.txt", "ras-base:no-allocation", true);
|
As per the RFC, bring in the ORTE async progress code and the rewrite of OOB:
*** THIS RFC INCLUDES A MINOR CHANGE TO THE MPI-RTE INTERFACE ***
Note: during the course of this work, it was necessary to completely separate the MPI and RTE progress engines. There were multiple places in the MPI layer where ORTE_WAIT_FOR_COMPLETION was being used. A new OMPI_WAIT_FOR_COMPLETION macro was created (defined in ompi/mca/rte/rte.h) that simply cycles across opal_progress until the provided flag becomes false. Places where the MPI layer blocked waiting for RTE to complete an event have been modified to use this macro.
***************************************************************************************
I am reissuing this RFC because of the time that has passed since its original release. Since its initial release and review, I have debugged it further to ensure it fully supports tests like loop_spawn. It therefore seems ready for merge back to the trunk. Given its prior review, I have set the timeout for one week.
The code is in https://bitbucket.org/rhc/ompi-oob2
WHAT: Rewrite of ORTE OOB
WHY: Support asynchronous progress and a host of other features
WHEN: Wed, August 21
SYNOPSIS:
The current OOB has served us well, but a number of limitations have been identified over the years. Specifically:
* it is only progressed when called via opal_progress, which can lead to hangs or recursive calls into libevent (which is not supported by that code)
* we've had issues when multiple NICs are available as the code doesn't "shift" messages between transports - thus, all nodes had to be available via the same TCP interface.
* the OOB "unloads" incoming opal_buffer_t objects during the transmission, thus preventing use of OBJ_RETAIN in the code when repeatedly sending the same message to multiple recipients
* there is no failover mechanism across NICs - if the selected NIC (or its attached switch) fails, we are forced to abort
* only one transport (i.e., component) can be "active"
The revised OOB resolves these problems:
* async progress is used for all application processes, with the progress thread blocking in the event library
* each available TCP NIC is supported by its own TCP module. The ability to asynchronously progress each module independently is provided, but not enabled by default (a runtime MCA parameter turns it "on")
* multi-address TCP NICs (e.g., a NIC with both an IPv4 and IPv6 address, or with virtual interfaces) are supported - reachability is determined by comparing the contact info for a peer against all addresses within the range covered by the address/mask pairs for the NIC.
* a message that arrives on one TCP NIC is automatically shifted to whatever NIC that is connected to the next "hop" if that peer cannot be reached by the incoming NIC. If no TCP module will reach the peer, then the OOB attempts to send the message via all other available components - if none can reach the peer, then an "error" is reported back to the RML, which then calls the errmgr for instructions.
* opal_buffer_t now conforms to standard object rules re OBJ_RETAIN as we no longer "unload" the incoming object
* NIC failure is reported to the TCP component, which then tries to resend the message across any other available TCP NIC. If that doesn't work, then the message is given back to the OOB base to try using other components. If all that fails, then the error is reported to the RML, which reports to the errmgr for instructions
* obviously from the above, multiple OOB components (e.g., TCP and UD) can be active in parallel
* the matching code has been moved to the RML (and out of the OOB/TCP component) so it is independent of transport
* routing is done by the individual OOB modules (as opposed to the RML). Thus, both routed and non-routed transports can simultaneously be active
* all blocking send/recv APIs have been removed. Everything operates asynchronously.
KNOWN LIMITATIONS:
* although provision is made for component failover as described above, the code for doing so has not been fully implemented yet. At the moment, if all connections for a given peer fail, the errmgr is notified of a "lost connection", which by default results in termination of the job if it was a lifeline
* the IPv6 code is present and compiles, but is not complete. Since the current IPv6 support in the OOB doesn't work anyway, I don't consider this a blocker
* routing is performed at the individual module level, yet the active routed component is selected on a global basis. We probably should update that to reflect that different transports may need/choose to route in different ways
* obviously, not every error path has been tested nor necessarily covered
* determining abnormal termination is more challenging than in the old code as we now potentially have multiple ways of connecting to a process. Ideally, we would declare "connection failed" when *all* transports can no longer reach the process, but that requires some additional (possibly complex) code. For now, the code replicates the old behavior only somewhat modified - i.e., if a module sees its connection fail, it checks to see if it is a lifeline. If so, it notifies the errmgr that the lifeline is lost - otherwise, it notifies the errmgr that a non-lifeline connection was lost.
* reachability is determined solely on the basis of a shared subnet address/mask - more sophisticated algorithms (e.g., the one used in the tcp btl) are required to handle routing via gateways
* the RML needs to assign sequence numbers to each message on a per-peer basis. The receiving RML will then deliver messages in order, thus preventing out-of-order messaging in the case where messages travel across different transports or a message needs to be redirected/resent due to failure of a NIC
This commit was SVN r29058.
2013-08-22 16:37:40 +00:00
|
|
|
ORTE_FORCED_TERMINATE(ORTE_ERROR_DEFAULT_EXIT_CODE);
|
2013-01-20 00:33:42 +00:00
|
|
|
OBJ_RELEASE(caddy);
|
|
|
|
return;
|
|
|
|
} else {
|
|
|
|
/* an allocation is not required, so we can just
|
|
|
|
* run on the local node - go add it
|
|
|
|
*/
|
|
|
|
goto addlocal;
|
|
|
|
}
|
|
|
|
}
|
2008-02-28 01:57:57 +00:00
|
|
|
ORTE_ERROR_LOG(rc);
|
|
|
|
OBJ_DESTRUCT(&nodes);
|
As per the RFC, bring in the ORTE async progress code and the rewrite of OOB:
*** THIS RFC INCLUDES A MINOR CHANGE TO THE MPI-RTE INTERFACE ***
Note: during the course of this work, it was necessary to completely separate the MPI and RTE progress engines. There were multiple places in the MPI layer where ORTE_WAIT_FOR_COMPLETION was being used. A new OMPI_WAIT_FOR_COMPLETION macro was created (defined in ompi/mca/rte/rte.h) that simply cycles across opal_progress until the provided flag becomes false. Places where the MPI layer blocked waiting for RTE to complete an event have been modified to use this macro.
***************************************************************************************
I am reissuing this RFC because of the time that has passed since its original release. Since its initial release and review, I have debugged it further to ensure it fully supports tests like loop_spawn. It therefore seems ready for merge back to the trunk. Given its prior review, I have set the timeout for one week.
The code is in https://bitbucket.org/rhc/ompi-oob2
WHAT: Rewrite of ORTE OOB
WHY: Support asynchronous progress and a host of other features
WHEN: Wed, August 21
SYNOPSIS:
The current OOB has served us well, but a number of limitations have been identified over the years. Specifically:
* it is only progressed when called via opal_progress, which can lead to hangs or recursive calls into libevent (which is not supported by that code)
* we've had issues when multiple NICs are available as the code doesn't "shift" messages between transports - thus, all nodes had to be available via the same TCP interface.
* the OOB "unloads" incoming opal_buffer_t objects during the transmission, thus preventing use of OBJ_RETAIN in the code when repeatedly sending the same message to multiple recipients
* there is no failover mechanism across NICs - if the selected NIC (or its attached switch) fails, we are forced to abort
* only one transport (i.e., component) can be "active"
The revised OOB resolves these problems:
* async progress is used for all application processes, with the progress thread blocking in the event library
* each available TCP NIC is supported by its own TCP module. The ability to asynchronously progress each module independently is provided, but not enabled by default (a runtime MCA parameter turns it "on")
* multi-address TCP NICs (e.g., a NIC with both an IPv4 and IPv6 address, or with virtual interfaces) are supported - reachability is determined by comparing the contact info for a peer against all addresses within the range covered by the address/mask pairs for the NIC.
* a message that arrives on one TCP NIC is automatically shifted to whatever NIC that is connected to the next "hop" if that peer cannot be reached by the incoming NIC. If no TCP module will reach the peer, then the OOB attempts to send the message via all other available components - if none can reach the peer, then an "error" is reported back to the RML, which then calls the errmgr for instructions.
* opal_buffer_t now conforms to standard object rules re OBJ_RETAIN as we no longer "unload" the incoming object
* NIC failure is reported to the TCP component, which then tries to resend the message across any other available TCP NIC. If that doesn't work, then the message is given back to the OOB base to try using other components. If all that fails, then the error is reported to the RML, which reports to the errmgr for instructions
* obviously from the above, multiple OOB components (e.g., TCP and UD) can be active in parallel
* the matching code has been moved to the RML (and out of the OOB/TCP component) so it is independent of transport
* routing is done by the individual OOB modules (as opposed to the RML). Thus, both routed and non-routed transports can simultaneously be active
* all blocking send/recv APIs have been removed. Everything operates asynchronously.
KNOWN LIMITATIONS:
* although provision is made for component failover as described above, the code for doing so has not been fully implemented yet. At the moment, if all connections for a given peer fail, the errmgr is notified of a "lost connection", which by default results in termination of the job if it was a lifeline
* the IPv6 code is present and compiles, but is not complete. Since the current IPv6 support in the OOB doesn't work anyway, I don't consider this a blocker
* routing is performed at the individual module level, yet the active routed component is selected on a global basis. We probably should update that to reflect that different transports may need/choose to route in different ways
* obviously, not every error path has been tested nor necessarily covered
* determining abnormal termination is more challenging than in the old code as we now potentially have multiple ways of connecting to a process. Ideally, we would declare "connection failed" when *all* transports can no longer reach the process, but that requires some additional (possibly complex) code. For now, the code replicates the old behavior only somewhat modified - i.e., if a module sees its connection fail, it checks to see if it is a lifeline. If so, it notifies the errmgr that the lifeline is lost - otherwise, it notifies the errmgr that a non-lifeline connection was lost.
* reachability is determined solely on the basis of a shared subnet address/mask - more sophisticated algorithms (e.g., the one used in the tcp btl) are required to handle routing via gateways
* the RML needs to assign sequence numbers to each message on a per-peer basis. The receiving RML will then deliver messages in order, thus preventing out-of-order messaging in the case where messages travel across different transports or a message needs to be redirected/resent due to failure of a NIC
This commit was SVN r29058.
2013-08-22 16:37:40 +00:00
|
|
|
ORTE_FORCED_TERMINATE(ORTE_ERROR_DEFAULT_EXIT_CODE);
|
2012-04-06 14:23:13 +00:00
|
|
|
OBJ_RELEASE(caddy);
|
|
|
|
return;
|
2006-10-19 23:33:51 +00:00
|
|
|
}
|
2015-06-23 20:59:57 -07:00
|
|
|
}
|
2008-02-28 01:57:57 +00:00
|
|
|
/* If something came back, save it and we are done */
|
|
|
|
if (!opal_list_is_empty(&nodes)) {
|
2015-03-16 16:25:01 -07:00
|
|
|
/* flag that the allocation is managed */
|
|
|
|
orte_managed_allocation = true;
|
|
|
|
/* since it is managed, we do not attempt to resolve
|
|
|
|
* the nodenames */
|
|
|
|
opal_if_do_not_resolve = true;
|
2008-02-28 01:57:57 +00:00
|
|
|
/* store the results in the global resource pool - this removes the
|
2012-04-06 14:23:13 +00:00
|
|
|
* list items
|
|
|
|
*/
|
2008-02-28 01:57:57 +00:00
|
|
|
if (ORTE_SUCCESS != (rc = orte_ras_base_node_insert(&nodes, jdata))) {
|
|
|
|
ORTE_ERROR_LOG(rc);
|
|
|
|
OBJ_DESTRUCT(&nodes);
|
As per the RFC, bring in the ORTE async progress code and the rewrite of OOB:
*** THIS RFC INCLUDES A MINOR CHANGE TO THE MPI-RTE INTERFACE ***
Note: during the course of this work, it was necessary to completely separate the MPI and RTE progress engines. There were multiple places in the MPI layer where ORTE_WAIT_FOR_COMPLETION was being used. A new OMPI_WAIT_FOR_COMPLETION macro was created (defined in ompi/mca/rte/rte.h) that simply cycles across opal_progress until the provided flag becomes false. Places where the MPI layer blocked waiting for RTE to complete an event have been modified to use this macro.
***************************************************************************************
I am reissuing this RFC because of the time that has passed since its original release. Since its initial release and review, I have debugged it further to ensure it fully supports tests like loop_spawn. It therefore seems ready for merge back to the trunk. Given its prior review, I have set the timeout for one week.
The code is in https://bitbucket.org/rhc/ompi-oob2
WHAT: Rewrite of ORTE OOB
WHY: Support asynchronous progress and a host of other features
WHEN: Wed, August 21
SYNOPSIS:
The current OOB has served us well, but a number of limitations have been identified over the years. Specifically:
* it is only progressed when called via opal_progress, which can lead to hangs or recursive calls into libevent (which is not supported by that code)
* we've had issues when multiple NICs are available as the code doesn't "shift" messages between transports - thus, all nodes had to be available via the same TCP interface.
* the OOB "unloads" incoming opal_buffer_t objects during the transmission, thus preventing use of OBJ_RETAIN in the code when repeatedly sending the same message to multiple recipients
* there is no failover mechanism across NICs - if the selected NIC (or its attached switch) fails, we are forced to abort
* only one transport (i.e., component) can be "active"
The revised OOB resolves these problems:
* async progress is used for all application processes, with the progress thread blocking in the event library
* each available TCP NIC is supported by its own TCP module. The ability to asynchronously progress each module independently is provided, but not enabled by default (a runtime MCA parameter turns it "on")
* multi-address TCP NICs (e.g., a NIC with both an IPv4 and IPv6 address, or with virtual interfaces) are supported - reachability is determined by comparing the contact info for a peer against all addresses within the range covered by the address/mask pairs for the NIC.
* a message that arrives on one TCP NIC is automatically shifted to whatever NIC that is connected to the next "hop" if that peer cannot be reached by the incoming NIC. If no TCP module will reach the peer, then the OOB attempts to send the message via all other available components - if none can reach the peer, then an "error" is reported back to the RML, which then calls the errmgr for instructions.
* opal_buffer_t now conforms to standard object rules re OBJ_RETAIN as we no longer "unload" the incoming object
* NIC failure is reported to the TCP component, which then tries to resend the message across any other available TCP NIC. If that doesn't work, then the message is given back to the OOB base to try using other components. If all that fails, then the error is reported to the RML, which reports to the errmgr for instructions
* obviously from the above, multiple OOB components (e.g., TCP and UD) can be active in parallel
* the matching code has been moved to the RML (and out of the OOB/TCP component) so it is independent of transport
* routing is done by the individual OOB modules (as opposed to the RML). Thus, both routed and non-routed transports can simultaneously be active
* all blocking send/recv APIs have been removed. Everything operates asynchronously.
KNOWN LIMITATIONS:
* although provision is made for component failover as described above, the code for doing so has not been fully implemented yet. At the moment, if all connections for a given peer fail, the errmgr is notified of a "lost connection", which by default results in termination of the job if it was a lifeline
* the IPv6 code is present and compiles, but is not complete. Since the current IPv6 support in the OOB doesn't work anyway, I don't consider this a blocker
* routing is performed at the individual module level, yet the active routed component is selected on a global basis. We probably should update that to reflect that different transports may need/choose to route in different ways
* obviously, not every error path has been tested nor necessarily covered
* determining abnormal termination is more challenging than in the old code as we now potentially have multiple ways of connecting to a process. Ideally, we would declare "connection failed" when *all* transports can no longer reach the process, but that requires some additional (possibly complex) code. For now, the code replicates the old behavior only somewhat modified - i.e., if a module sees its connection fail, it checks to see if it is a lifeline. If so, it notifies the errmgr that the lifeline is lost - otherwise, it notifies the errmgr that a non-lifeline connection was lost.
* reachability is determined solely on the basis of a shared subnet address/mask - more sophisticated algorithms (e.g., the one used in the tcp btl) are required to handle routing via gateways
* the RML needs to assign sequence numbers to each message on a per-peer basis. The receiving RML will then deliver messages in order, thus preventing out-of-order messaging in the case where messages travel across different transports or a message needs to be redirected/resent due to failure of a NIC
This commit was SVN r29058.
2013-08-22 16:37:40 +00:00
|
|
|
ORTE_FORCED_TERMINATE(ORTE_ERROR_DEFAULT_EXIT_CODE);
|
2012-04-06 14:23:13 +00:00
|
|
|
OBJ_RELEASE(caddy);
|
|
|
|
return;
|
2006-10-19 23:33:51 +00:00
|
|
|
}
|
2008-02-28 01:57:57 +00:00
|
|
|
OBJ_DESTRUCT(&nodes);
|
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 03:40:11 +00:00
|
|
|
/* default to no-oversubscribe-allowed for managed systems */
|
|
|
|
if (!(ORTE_MAPPING_SUBSCRIBE_GIVEN & ORTE_GET_MAPPING_DIRECTIVE(orte_rmaps_base.mapping))) {
|
|
|
|
ORTE_SET_MAPPING_DIRECTIVE(orte_rmaps_base.mapping, ORTE_MAPPING_NO_OVERSUBSCRIBE);
|
|
|
|
}
|
2008-04-21 20:28:59 +00:00
|
|
|
goto DISPLAY;
|
2008-08-04 14:25:19 +00:00
|
|
|
} else if (orte_allocation_required) {
|
|
|
|
/* if nothing was found, and an allocation is
|
|
|
|
* required, then error out
|
|
|
|
*/
|
|
|
|
OBJ_DESTRUCT(&nodes);
|
|
|
|
orte_show_help("help-ras-base.txt", "ras-base:no-allocation", true);
|
As per the RFC, bring in the ORTE async progress code and the rewrite of OOB:
*** THIS RFC INCLUDES A MINOR CHANGE TO THE MPI-RTE INTERFACE ***
Note: during the course of this work, it was necessary to completely separate the MPI and RTE progress engines. There were multiple places in the MPI layer where ORTE_WAIT_FOR_COMPLETION was being used. A new OMPI_WAIT_FOR_COMPLETION macro was created (defined in ompi/mca/rte/rte.h) that simply cycles across opal_progress until the provided flag becomes false. Places where the MPI layer blocked waiting for RTE to complete an event have been modified to use this macro.
***************************************************************************************
I am reissuing this RFC because of the time that has passed since its original release. Since its initial release and review, I have debugged it further to ensure it fully supports tests like loop_spawn. It therefore seems ready for merge back to the trunk. Given its prior review, I have set the timeout for one week.
The code is in https://bitbucket.org/rhc/ompi-oob2
WHAT: Rewrite of ORTE OOB
WHY: Support asynchronous progress and a host of other features
WHEN: Wed, August 21
SYNOPSIS:
The current OOB has served us well, but a number of limitations have been identified over the years. Specifically:
* it is only progressed when called via opal_progress, which can lead to hangs or recursive calls into libevent (which is not supported by that code)
* we've had issues when multiple NICs are available as the code doesn't "shift" messages between transports - thus, all nodes had to be available via the same TCP interface.
* the OOB "unloads" incoming opal_buffer_t objects during the transmission, thus preventing use of OBJ_RETAIN in the code when repeatedly sending the same message to multiple recipients
* there is no failover mechanism across NICs - if the selected NIC (or its attached switch) fails, we are forced to abort
* only one transport (i.e., component) can be "active"
The revised OOB resolves these problems:
* async progress is used for all application processes, with the progress thread blocking in the event library
* each available TCP NIC is supported by its own TCP module. The ability to asynchronously progress each module independently is provided, but not enabled by default (a runtime MCA parameter turns it "on")
* multi-address TCP NICs (e.g., a NIC with both an IPv4 and IPv6 address, or with virtual interfaces) are supported - reachability is determined by comparing the contact info for a peer against all addresses within the range covered by the address/mask pairs for the NIC.
* a message that arrives on one TCP NIC is automatically shifted to whatever NIC that is connected to the next "hop" if that peer cannot be reached by the incoming NIC. If no TCP module will reach the peer, then the OOB attempts to send the message via all other available components - if none can reach the peer, then an "error" is reported back to the RML, which then calls the errmgr for instructions.
* opal_buffer_t now conforms to standard object rules re OBJ_RETAIN as we no longer "unload" the incoming object
* NIC failure is reported to the TCP component, which then tries to resend the message across any other available TCP NIC. If that doesn't work, then the message is given back to the OOB base to try using other components. If all that fails, then the error is reported to the RML, which reports to the errmgr for instructions
* obviously from the above, multiple OOB components (e.g., TCP and UD) can be active in parallel
* the matching code has been moved to the RML (and out of the OOB/TCP component) so it is independent of transport
* routing is done by the individual OOB modules (as opposed to the RML). Thus, both routed and non-routed transports can simultaneously be active
* all blocking send/recv APIs have been removed. Everything operates asynchronously.
KNOWN LIMITATIONS:
* although provision is made for component failover as described above, the code for doing so has not been fully implemented yet. At the moment, if all connections for a given peer fail, the errmgr is notified of a "lost connection", which by default results in termination of the job if it was a lifeline
* the IPv6 code is present and compiles, but is not complete. Since the current IPv6 support in the OOB doesn't work anyway, I don't consider this a blocker
* routing is performed at the individual module level, yet the active routed component is selected on a global basis. We probably should update that to reflect that different transports may need/choose to route in different ways
* obviously, not every error path has been tested nor necessarily covered
* determining abnormal termination is more challenging than in the old code as we now potentially have multiple ways of connecting to a process. Ideally, we would declare "connection failed" when *all* transports can no longer reach the process, but that requires some additional (possibly complex) code. For now, the code replicates the old behavior only somewhat modified - i.e., if a module sees its connection fail, it checks to see if it is a lifeline. If so, it notifies the errmgr that the lifeline is lost - otherwise, it notifies the errmgr that a non-lifeline connection was lost.
* reachability is determined solely on the basis of a shared subnet address/mask - more sophisticated algorithms (e.g., the one used in the tcp btl) are required to handle routing via gateways
* the RML needs to assign sequence numbers to each message on a per-peer basis. The receiving RML will then deliver messages in order, thus preventing out-of-order messaging in the case where messages travel across different transports or a message needs to be redirected/resent due to failure of a NIC
This commit was SVN r29058.
2013-08-22 16:37:40 +00:00
|
|
|
ORTE_FORCED_TERMINATE(ORTE_ERROR_DEFAULT_EXIT_CODE);
|
2012-04-06 14:23:13 +00:00
|
|
|
OBJ_RELEASE(caddy);
|
|
|
|
return;
|
2006-10-19 23:33:51 +00:00
|
|
|
}
|
2015-06-23 20:59:57 -07:00
|
|
|
|
2013-03-27 21:14:43 +00:00
|
|
|
OPAL_OUTPUT_VERBOSE((5, orte_ras_base_framework.framework_output,
|
2008-02-28 01:57:57 +00:00
|
|
|
"%s ras:base:allocate nothing found in module - proceeding to hostfile",
|
2009-03-05 21:50:47 +00:00
|
|
|
ORTE_NAME_PRINT(ORTE_PROC_MY_NAME)));
|
2015-06-23 20:59:57 -07:00
|
|
|
|
2008-02-28 01:57:57 +00:00
|
|
|
/* nothing was found, or no active module was alive. Our next
|
|
|
|
* option is to look for a hostfile and assign our global
|
2012-09-04 11:50:52 +00:00
|
|
|
* pool from there.
|
2008-08-19 15:17:40 +00:00
|
|
|
*
|
2012-09-04 11:50:52 +00:00
|
|
|
* Individual hostfile names, if given, are included
|
2008-02-28 01:57:57 +00:00
|
|
|
* in the app_contexts for this job. We therefore need to
|
|
|
|
* retrieve the app_contexts for the job, and then cycle
|
|
|
|
* through them to see if anything is there. The parser will
|
|
|
|
* add the nodes found in each hostfile to our list - i.e.,
|
|
|
|
* the resulting list contains the UNION of all nodes specified
|
|
|
|
* in hostfiles from across all app_contexts
|
2008-08-19 15:17:40 +00:00
|
|
|
*
|
2013-12-21 01:38:27 +00:00
|
|
|
* We then continue to add any hosts provided by dash-host and
|
|
|
|
* the default hostfile, if we have it. We will then filter out
|
|
|
|
* all the non-desired hosts (i.e., those not specified by
|
|
|
|
* -host and/or -hostfile) when we start the mapping process
|
2012-09-04 16:34:05 +00:00
|
|
|
*
|
2008-08-19 15:17:40 +00:00
|
|
|
* Note that any relative node syntax found in the hostfiles will
|
|
|
|
* generate an error in this scenario, so only non-relative syntax
|
|
|
|
* can be present
|
2008-02-28 01:57:57 +00:00
|
|
|
*/
|
2013-12-21 01:38:27 +00:00
|
|
|
if (NULL != orte_default_hostfile) {
|
|
|
|
OPAL_OUTPUT_VERBOSE((5, orte_ras_base_framework.framework_output,
|
|
|
|
"%s ras:base:allocate parsing default hostfile %s",
|
|
|
|
ORTE_NAME_PRINT(ORTE_PROC_MY_NAME),
|
|
|
|
orte_default_hostfile));
|
2015-06-23 20:59:57 -07:00
|
|
|
|
2013-12-21 01:38:27 +00:00
|
|
|
/* a default hostfile was provided - parse it */
|
|
|
|
if (ORTE_SUCCESS != (rc = orte_util_add_hostfile_nodes(&nodes,
|
|
|
|
orte_default_hostfile))) {
|
|
|
|
OBJ_DESTRUCT(&nodes);
|
|
|
|
ORTE_FORCED_TERMINATE(ORTE_ERROR_DEFAULT_EXIT_CODE);
|
|
|
|
OBJ_RELEASE(caddy);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
}
|
2014-01-02 16:07:16 +00:00
|
|
|
if (NULL != orte_rankfile) {
|
|
|
|
OPAL_OUTPUT_VERBOSE((5, orte_ras_base_framework.framework_output,
|
|
|
|
"%s ras:base:allocate parsing rankfile %s",
|
|
|
|
ORTE_NAME_PRINT(ORTE_PROC_MY_NAME),
|
|
|
|
orte_rankfile));
|
2015-06-23 20:59:57 -07:00
|
|
|
|
2014-01-02 16:07:16 +00:00
|
|
|
/* a rankfile was provided - parse it */
|
|
|
|
if (ORTE_SUCCESS != (rc = orte_util_add_hostfile_nodes(&nodes,
|
|
|
|
orte_rankfile))) {
|
|
|
|
OBJ_DESTRUCT(&nodes);
|
|
|
|
ORTE_FORCED_TERMINATE(ORTE_ERROR_DEFAULT_EXIT_CODE);
|
|
|
|
OBJ_RELEASE(caddy);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
}
|
2009-07-14 14:34:11 +00:00
|
|
|
for (i=0; i < jdata->apps->size; i++) {
|
|
|
|
if (NULL == (app = (orte_app_context_t*)opal_pointer_array_get_item(jdata->apps, i))) {
|
|
|
|
continue;
|
|
|
|
}
|
2014-06-01 16:14:10 +00:00
|
|
|
if (orte_get_attribute(&app->attributes, ORTE_APP_HOSTFILE, (void**)&hosts, OPAL_STRING)) {
|
2013-03-27 21:14:43 +00:00
|
|
|
OPAL_OUTPUT_VERBOSE((5, orte_ras_base_framework.framework_output,
|
2012-09-04 11:50:52 +00:00
|
|
|
"%s ras:base:allocate adding hostfile %s",
|
2014-06-01 16:14:10 +00:00
|
|
|
ORTE_NAME_PRINT(ORTE_PROC_MY_NAME), hosts));
|
2015-06-23 20:59:57 -07:00
|
|
|
|
2008-02-28 01:57:57 +00:00
|
|
|
/* hostfile was specified - parse it and add it to the list */
|
2014-06-01 16:14:10 +00:00
|
|
|
if (ORTE_SUCCESS != (rc = orte_util_add_hostfile_nodes(&nodes, hosts))) {
|
|
|
|
free(hosts);
|
2008-02-28 01:57:57 +00:00
|
|
|
OBJ_DESTRUCT(&nodes);
|
2012-04-06 14:23:13 +00:00
|
|
|
/* set an error event */
|
As per the RFC, bring in the ORTE async progress code and the rewrite of OOB:
*** THIS RFC INCLUDES A MINOR CHANGE TO THE MPI-RTE INTERFACE ***
Note: during the course of this work, it was necessary to completely separate the MPI and RTE progress engines. There were multiple places in the MPI layer where ORTE_WAIT_FOR_COMPLETION was being used. A new OMPI_WAIT_FOR_COMPLETION macro was created (defined in ompi/mca/rte/rte.h) that simply cycles across opal_progress until the provided flag becomes false. Places where the MPI layer blocked waiting for RTE to complete an event have been modified to use this macro.
***************************************************************************************
I am reissuing this RFC because of the time that has passed since its original release. Since its initial release and review, I have debugged it further to ensure it fully supports tests like loop_spawn. It therefore seems ready for merge back to the trunk. Given its prior review, I have set the timeout for one week.
The code is in https://bitbucket.org/rhc/ompi-oob2
WHAT: Rewrite of ORTE OOB
WHY: Support asynchronous progress and a host of other features
WHEN: Wed, August 21
SYNOPSIS:
The current OOB has served us well, but a number of limitations have been identified over the years. Specifically:
* it is only progressed when called via opal_progress, which can lead to hangs or recursive calls into libevent (which is not supported by that code)
* we've had issues when multiple NICs are available as the code doesn't "shift" messages between transports - thus, all nodes had to be available via the same TCP interface.
* the OOB "unloads" incoming opal_buffer_t objects during the transmission, thus preventing use of OBJ_RETAIN in the code when repeatedly sending the same message to multiple recipients
* there is no failover mechanism across NICs - if the selected NIC (or its attached switch) fails, we are forced to abort
* only one transport (i.e., component) can be "active"
The revised OOB resolves these problems:
* async progress is used for all application processes, with the progress thread blocking in the event library
* each available TCP NIC is supported by its own TCP module. The ability to asynchronously progress each module independently is provided, but not enabled by default (a runtime MCA parameter turns it "on")
* multi-address TCP NICs (e.g., a NIC with both an IPv4 and IPv6 address, or with virtual interfaces) are supported - reachability is determined by comparing the contact info for a peer against all addresses within the range covered by the address/mask pairs for the NIC.
* a message that arrives on one TCP NIC is automatically shifted to whatever NIC that is connected to the next "hop" if that peer cannot be reached by the incoming NIC. If no TCP module will reach the peer, then the OOB attempts to send the message via all other available components - if none can reach the peer, then an "error" is reported back to the RML, which then calls the errmgr for instructions.
* opal_buffer_t now conforms to standard object rules re OBJ_RETAIN as we no longer "unload" the incoming object
* NIC failure is reported to the TCP component, which then tries to resend the message across any other available TCP NIC. If that doesn't work, then the message is given back to the OOB base to try using other components. If all that fails, then the error is reported to the RML, which reports to the errmgr for instructions
* obviously from the above, multiple OOB components (e.g., TCP and UD) can be active in parallel
* the matching code has been moved to the RML (and out of the OOB/TCP component) so it is independent of transport
* routing is done by the individual OOB modules (as opposed to the RML). Thus, both routed and non-routed transports can simultaneously be active
* all blocking send/recv APIs have been removed. Everything operates asynchronously.
KNOWN LIMITATIONS:
* although provision is made for component failover as described above, the code for doing so has not been fully implemented yet. At the moment, if all connections for a given peer fail, the errmgr is notified of a "lost connection", which by default results in termination of the job if it was a lifeline
* the IPv6 code is present and compiles, but is not complete. Since the current IPv6 support in the OOB doesn't work anyway, I don't consider this a blocker
* routing is performed at the individual module level, yet the active routed component is selected on a global basis. We probably should update that to reflect that different transports may need/choose to route in different ways
* obviously, not every error path has been tested nor necessarily covered
* determining abnormal termination is more challenging than in the old code as we now potentially have multiple ways of connecting to a process. Ideally, we would declare "connection failed" when *all* transports can no longer reach the process, but that requires some additional (possibly complex) code. For now, the code replicates the old behavior only somewhat modified - i.e., if a module sees its connection fail, it checks to see if it is a lifeline. If so, it notifies the errmgr that the lifeline is lost - otherwise, it notifies the errmgr that a non-lifeline connection was lost.
* reachability is determined solely on the basis of a shared subnet address/mask - more sophisticated algorithms (e.g., the one used in the tcp btl) are required to handle routing via gateways
* the RML needs to assign sequence numbers to each message on a per-peer basis. The receiving RML will then deliver messages in order, thus preventing out-of-order messaging in the case where messages travel across different transports or a message needs to be redirected/resent due to failure of a NIC
This commit was SVN r29058.
2013-08-22 16:37:40 +00:00
|
|
|
ORTE_FORCED_TERMINATE(ORTE_ERROR_DEFAULT_EXIT_CODE);
|
2012-04-06 14:23:13 +00:00
|
|
|
OBJ_RELEASE(caddy);
|
|
|
|
return;
|
2005-10-07 22:24:52 +00:00
|
|
|
}
|
2014-06-01 16:14:10 +00:00
|
|
|
free(hosts);
|
|
|
|
} else if (!orte_soft_locations &&
|
|
|
|
orte_get_attribute(&app->attributes, ORTE_APP_DASH_HOST, (void**)&hosts, OPAL_STRING)) {
|
2012-09-05 18:42:09 +00:00
|
|
|
/* if we are using soft locations, then any dash-host would
|
|
|
|
* just include desired nodes and not required. We don't want
|
|
|
|
* to pick them up here as this would mean the request was
|
|
|
|
* always satisfied - instead, we want to allow the request
|
|
|
|
* to fail later on and use whatever nodes are actually
|
|
|
|
* available
|
|
|
|
*/
|
2013-03-27 21:14:43 +00:00
|
|
|
OPAL_OUTPUT_VERBOSE((5, orte_ras_base_framework.framework_output,
|
2012-09-04 17:22:17 +00:00
|
|
|
"%s ras:base:allocate adding dash_hosts",
|
|
|
|
ORTE_NAME_PRINT(ORTE_PROC_MY_NAME)));
|
2014-06-01 16:14:10 +00:00
|
|
|
if (ORTE_SUCCESS != (rc = orte_util_add_dash_host_nodes(&nodes, hosts))) {
|
|
|
|
free(hosts);
|
2008-02-28 01:57:57 +00:00
|
|
|
OBJ_DESTRUCT(&nodes);
|
As per the RFC, bring in the ORTE async progress code and the rewrite of OOB:
*** THIS RFC INCLUDES A MINOR CHANGE TO THE MPI-RTE INTERFACE ***
Note: during the course of this work, it was necessary to completely separate the MPI and RTE progress engines. There were multiple places in the MPI layer where ORTE_WAIT_FOR_COMPLETION was being used. A new OMPI_WAIT_FOR_COMPLETION macro was created (defined in ompi/mca/rte/rte.h) that simply cycles across opal_progress until the provided flag becomes false. Places where the MPI layer blocked waiting for RTE to complete an event have been modified to use this macro.
***************************************************************************************
I am reissuing this RFC because of the time that has passed since its original release. Since its initial release and review, I have debugged it further to ensure it fully supports tests like loop_spawn. It therefore seems ready for merge back to the trunk. Given its prior review, I have set the timeout for one week.
The code is in https://bitbucket.org/rhc/ompi-oob2
WHAT: Rewrite of ORTE OOB
WHY: Support asynchronous progress and a host of other features
WHEN: Wed, August 21
SYNOPSIS:
The current OOB has served us well, but a number of limitations have been identified over the years. Specifically:
* it is only progressed when called via opal_progress, which can lead to hangs or recursive calls into libevent (which is not supported by that code)
* we've had issues when multiple NICs are available as the code doesn't "shift" messages between transports - thus, all nodes had to be available via the same TCP interface.
* the OOB "unloads" incoming opal_buffer_t objects during the transmission, thus preventing use of OBJ_RETAIN in the code when repeatedly sending the same message to multiple recipients
* there is no failover mechanism across NICs - if the selected NIC (or its attached switch) fails, we are forced to abort
* only one transport (i.e., component) can be "active"
The revised OOB resolves these problems:
* async progress is used for all application processes, with the progress thread blocking in the event library
* each available TCP NIC is supported by its own TCP module. The ability to asynchronously progress each module independently is provided, but not enabled by default (a runtime MCA parameter turns it "on")
* multi-address TCP NICs (e.g., a NIC with both an IPv4 and IPv6 address, or with virtual interfaces) are supported - reachability is determined by comparing the contact info for a peer against all addresses within the range covered by the address/mask pairs for the NIC.
* a message that arrives on one TCP NIC is automatically shifted to whatever NIC that is connected to the next "hop" if that peer cannot be reached by the incoming NIC. If no TCP module will reach the peer, then the OOB attempts to send the message via all other available components - if none can reach the peer, then an "error" is reported back to the RML, which then calls the errmgr for instructions.
* opal_buffer_t now conforms to standard object rules re OBJ_RETAIN as we no longer "unload" the incoming object
* NIC failure is reported to the TCP component, which then tries to resend the message across any other available TCP NIC. If that doesn't work, then the message is given back to the OOB base to try using other components. If all that fails, then the error is reported to the RML, which reports to the errmgr for instructions
* obviously from the above, multiple OOB components (e.g., TCP and UD) can be active in parallel
* the matching code has been moved to the RML (and out of the OOB/TCP component) so it is independent of transport
* routing is done by the individual OOB modules (as opposed to the RML). Thus, both routed and non-routed transports can simultaneously be active
* all blocking send/recv APIs have been removed. Everything operates asynchronously.
KNOWN LIMITATIONS:
* although provision is made for component failover as described above, the code for doing so has not been fully implemented yet. At the moment, if all connections for a given peer fail, the errmgr is notified of a "lost connection", which by default results in termination of the job if it was a lifeline
* the IPv6 code is present and compiles, but is not complete. Since the current IPv6 support in the OOB doesn't work anyway, I don't consider this a blocker
* routing is performed at the individual module level, yet the active routed component is selected on a global basis. We probably should update that to reflect that different transports may need/choose to route in different ways
* obviously, not every error path has been tested nor necessarily covered
* determining abnormal termination is more challenging than in the old code as we now potentially have multiple ways of connecting to a process. Ideally, we would declare "connection failed" when *all* transports can no longer reach the process, but that requires some additional (possibly complex) code. For now, the code replicates the old behavior only somewhat modified - i.e., if a module sees its connection fail, it checks to see if it is a lifeline. If so, it notifies the errmgr that the lifeline is lost - otherwise, it notifies the errmgr that a non-lifeline connection was lost.
* reachability is determined solely on the basis of a shared subnet address/mask - more sophisticated algorithms (e.g., the one used in the tcp btl) are required to handle routing via gateways
* the RML needs to assign sequence numbers to each message on a per-peer basis. The receiving RML will then deliver messages in order, thus preventing out-of-order messaging in the case where messages travel across different transports or a message needs to be redirected/resent due to failure of a NIC
This commit was SVN r29058.
2013-08-22 16:37:40 +00:00
|
|
|
ORTE_FORCED_TERMINATE(ORTE_ERROR_DEFAULT_EXIT_CODE);
|
2012-04-06 14:23:13 +00:00
|
|
|
OBJ_RELEASE(caddy);
|
|
|
|
return;
|
2006-10-31 22:16:51 +00:00
|
|
|
}
|
2014-06-01 16:14:10 +00:00
|
|
|
free(hosts);
|
2006-10-31 22:16:51 +00:00
|
|
|
}
|
|
|
|
}
|
2005-10-07 22:24:52 +00:00
|
|
|
|
2012-09-04 11:50:52 +00:00
|
|
|
/* if something was found in the hostfile(s), we use that as our global
|
2008-02-28 01:57:57 +00:00
|
|
|
* pool - set it and we are done
|
|
|
|
*/
|
|
|
|
if (!opal_list_is_empty(&nodes)) {
|
|
|
|
/* store the results in the global resource pool - this removes the
|
|
|
|
* list items
|
|
|
|
*/
|
|
|
|
if (ORTE_SUCCESS != (rc = orte_ras_base_node_insert(&nodes, jdata))) {
|
|
|
|
ORTE_ERROR_LOG(rc);
|
As per the RFC, bring in the ORTE async progress code and the rewrite of OOB:
*** THIS RFC INCLUDES A MINOR CHANGE TO THE MPI-RTE INTERFACE ***
Note: during the course of this work, it was necessary to completely separate the MPI and RTE progress engines. There were multiple places in the MPI layer where ORTE_WAIT_FOR_COMPLETION was being used. A new OMPI_WAIT_FOR_COMPLETION macro was created (defined in ompi/mca/rte/rte.h) that simply cycles across opal_progress until the provided flag becomes false. Places where the MPI layer blocked waiting for RTE to complete an event have been modified to use this macro.
***************************************************************************************
I am reissuing this RFC because of the time that has passed since its original release. Since its initial release and review, I have debugged it further to ensure it fully supports tests like loop_spawn. It therefore seems ready for merge back to the trunk. Given its prior review, I have set the timeout for one week.
The code is in https://bitbucket.org/rhc/ompi-oob2
WHAT: Rewrite of ORTE OOB
WHY: Support asynchronous progress and a host of other features
WHEN: Wed, August 21
SYNOPSIS:
The current OOB has served us well, but a number of limitations have been identified over the years. Specifically:
* it is only progressed when called via opal_progress, which can lead to hangs or recursive calls into libevent (which is not supported by that code)
* we've had issues when multiple NICs are available as the code doesn't "shift" messages between transports - thus, all nodes had to be available via the same TCP interface.
* the OOB "unloads" incoming opal_buffer_t objects during the transmission, thus preventing use of OBJ_RETAIN in the code when repeatedly sending the same message to multiple recipients
* there is no failover mechanism across NICs - if the selected NIC (or its attached switch) fails, we are forced to abort
* only one transport (i.e., component) can be "active"
The revised OOB resolves these problems:
* async progress is used for all application processes, with the progress thread blocking in the event library
* each available TCP NIC is supported by its own TCP module. The ability to asynchronously progress each module independently is provided, but not enabled by default (a runtime MCA parameter turns it "on")
* multi-address TCP NICs (e.g., a NIC with both an IPv4 and IPv6 address, or with virtual interfaces) are supported - reachability is determined by comparing the contact info for a peer against all addresses within the range covered by the address/mask pairs for the NIC.
* a message that arrives on one TCP NIC is automatically shifted to whatever NIC that is connected to the next "hop" if that peer cannot be reached by the incoming NIC. If no TCP module will reach the peer, then the OOB attempts to send the message via all other available components - if none can reach the peer, then an "error" is reported back to the RML, which then calls the errmgr for instructions.
* opal_buffer_t now conforms to standard object rules re OBJ_RETAIN as we no longer "unload" the incoming object
* NIC failure is reported to the TCP component, which then tries to resend the message across any other available TCP NIC. If that doesn't work, then the message is given back to the OOB base to try using other components. If all that fails, then the error is reported to the RML, which reports to the errmgr for instructions
* obviously from the above, multiple OOB components (e.g., TCP and UD) can be active in parallel
* the matching code has been moved to the RML (and out of the OOB/TCP component) so it is independent of transport
* routing is done by the individual OOB modules (as opposed to the RML). Thus, both routed and non-routed transports can simultaneously be active
* all blocking send/recv APIs have been removed. Everything operates asynchronously.
KNOWN LIMITATIONS:
* although provision is made for component failover as described above, the code for doing so has not been fully implemented yet. At the moment, if all connections for a given peer fail, the errmgr is notified of a "lost connection", which by default results in termination of the job if it was a lifeline
* the IPv6 code is present and compiles, but is not complete. Since the current IPv6 support in the OOB doesn't work anyway, I don't consider this a blocker
* routing is performed at the individual module level, yet the active routed component is selected on a global basis. We probably should update that to reflect that different transports may need/choose to route in different ways
* obviously, not every error path has been tested nor necessarily covered
* determining abnormal termination is more challenging than in the old code as we now potentially have multiple ways of connecting to a process. Ideally, we would declare "connection failed" when *all* transports can no longer reach the process, but that requires some additional (possibly complex) code. For now, the code replicates the old behavior only somewhat modified - i.e., if a module sees its connection fail, it checks to see if it is a lifeline. If so, it notifies the errmgr that the lifeline is lost - otherwise, it notifies the errmgr that a non-lifeline connection was lost.
* reachability is determined solely on the basis of a shared subnet address/mask - more sophisticated algorithms (e.g., the one used in the tcp btl) are required to handle routing via gateways
* the RML needs to assign sequence numbers to each message on a per-peer basis. The receiving RML will then deliver messages in order, thus preventing out-of-order messaging in the case where messages travel across different transports or a message needs to be redirected/resent due to failure of a NIC
This commit was SVN r29058.
2013-08-22 16:37:40 +00:00
|
|
|
ORTE_FORCED_TERMINATE(ORTE_ERROR_DEFAULT_EXIT_CODE);
|
2012-04-06 14:23:13 +00:00
|
|
|
OBJ_RELEASE(caddy);
|
|
|
|
return;
|
2008-02-28 01:57:57 +00:00
|
|
|
}
|
|
|
|
/* cleanup */
|
|
|
|
OBJ_DESTRUCT(&nodes);
|
2008-04-21 20:28:59 +00:00
|
|
|
goto DISPLAY;
|
2006-10-19 23:33:51 +00:00
|
|
|
}
|
2015-06-23 20:59:57 -07:00
|
|
|
|
2013-03-27 21:14:43 +00:00
|
|
|
OPAL_OUTPUT_VERBOSE((5, orte_ras_base_framework.framework_output,
|
2012-09-04 11:50:52 +00:00
|
|
|
"%s ras:base:allocate nothing found in hostfiles - checking for rankfile",
|
2009-08-13 16:08:43 +00:00
|
|
|
ORTE_NAME_PRINT(ORTE_PROC_MY_NAME)));
|
2015-06-23 20:59:57 -07:00
|
|
|
|
2009-08-13 16:08:43 +00:00
|
|
|
/* Our next option is to look for a rankfile - if one was provided, we
|
|
|
|
* will use its nodes to create a default allocation pool
|
|
|
|
*/
|
|
|
|
if (NULL != orte_rankfile) {
|
|
|
|
/* check the rankfile for node information */
|
|
|
|
if (ORTE_SUCCESS != (rc = orte_util_add_hostfile_nodes(&nodes,
|
|
|
|
orte_rankfile))) {
|
|
|
|
ORTE_ERROR_LOG(rc);
|
|
|
|
OBJ_DESTRUCT(&nodes);
|
As per the RFC, bring in the ORTE async progress code and the rewrite of OOB:
*** THIS RFC INCLUDES A MINOR CHANGE TO THE MPI-RTE INTERFACE ***
Note: during the course of this work, it was necessary to completely separate the MPI and RTE progress engines. There were multiple places in the MPI layer where ORTE_WAIT_FOR_COMPLETION was being used. A new OMPI_WAIT_FOR_COMPLETION macro was created (defined in ompi/mca/rte/rte.h) that simply cycles across opal_progress until the provided flag becomes false. Places where the MPI layer blocked waiting for RTE to complete an event have been modified to use this macro.
***************************************************************************************
I am reissuing this RFC because of the time that has passed since its original release. Since its initial release and review, I have debugged it further to ensure it fully supports tests like loop_spawn. It therefore seems ready for merge back to the trunk. Given its prior review, I have set the timeout for one week.
The code is in https://bitbucket.org/rhc/ompi-oob2
WHAT: Rewrite of ORTE OOB
WHY: Support asynchronous progress and a host of other features
WHEN: Wed, August 21
SYNOPSIS:
The current OOB has served us well, but a number of limitations have been identified over the years. Specifically:
* it is only progressed when called via opal_progress, which can lead to hangs or recursive calls into libevent (which is not supported by that code)
* we've had issues when multiple NICs are available as the code doesn't "shift" messages between transports - thus, all nodes had to be available via the same TCP interface.
* the OOB "unloads" incoming opal_buffer_t objects during the transmission, thus preventing use of OBJ_RETAIN in the code when repeatedly sending the same message to multiple recipients
* there is no failover mechanism across NICs - if the selected NIC (or its attached switch) fails, we are forced to abort
* only one transport (i.e., component) can be "active"
The revised OOB resolves these problems:
* async progress is used for all application processes, with the progress thread blocking in the event library
* each available TCP NIC is supported by its own TCP module. The ability to asynchronously progress each module independently is provided, but not enabled by default (a runtime MCA parameter turns it "on")
* multi-address TCP NICs (e.g., a NIC with both an IPv4 and IPv6 address, or with virtual interfaces) are supported - reachability is determined by comparing the contact info for a peer against all addresses within the range covered by the address/mask pairs for the NIC.
* a message that arrives on one TCP NIC is automatically shifted to whatever NIC that is connected to the next "hop" if that peer cannot be reached by the incoming NIC. If no TCP module will reach the peer, then the OOB attempts to send the message via all other available components - if none can reach the peer, then an "error" is reported back to the RML, which then calls the errmgr for instructions.
* opal_buffer_t now conforms to standard object rules re OBJ_RETAIN as we no longer "unload" the incoming object
* NIC failure is reported to the TCP component, which then tries to resend the message across any other available TCP NIC. If that doesn't work, then the message is given back to the OOB base to try using other components. If all that fails, then the error is reported to the RML, which reports to the errmgr for instructions
* obviously from the above, multiple OOB components (e.g., TCP and UD) can be active in parallel
* the matching code has been moved to the RML (and out of the OOB/TCP component) so it is independent of transport
* routing is done by the individual OOB modules (as opposed to the RML). Thus, both routed and non-routed transports can simultaneously be active
* all blocking send/recv APIs have been removed. Everything operates asynchronously.
KNOWN LIMITATIONS:
* although provision is made for component failover as described above, the code for doing so has not been fully implemented yet. At the moment, if all connections for a given peer fail, the errmgr is notified of a "lost connection", which by default results in termination of the job if it was a lifeline
* the IPv6 code is present and compiles, but is not complete. Since the current IPv6 support in the OOB doesn't work anyway, I don't consider this a blocker
* routing is performed at the individual module level, yet the active routed component is selected on a global basis. We probably should update that to reflect that different transports may need/choose to route in different ways
* obviously, not every error path has been tested nor necessarily covered
* determining abnormal termination is more challenging than in the old code as we now potentially have multiple ways of connecting to a process. Ideally, we would declare "connection failed" when *all* transports can no longer reach the process, but that requires some additional (possibly complex) code. For now, the code replicates the old behavior only somewhat modified - i.e., if a module sees its connection fail, it checks to see if it is a lifeline. If so, it notifies the errmgr that the lifeline is lost - otherwise, it notifies the errmgr that a non-lifeline connection was lost.
* reachability is determined solely on the basis of a shared subnet address/mask - more sophisticated algorithms (e.g., the one used in the tcp btl) are required to handle routing via gateways
* the RML needs to assign sequence numbers to each message on a per-peer basis. The receiving RML will then deliver messages in order, thus preventing out-of-order messaging in the case where messages travel across different transports or a message needs to be redirected/resent due to failure of a NIC
This commit was SVN r29058.
2013-08-22 16:37:40 +00:00
|
|
|
ORTE_FORCED_TERMINATE(ORTE_ERROR_DEFAULT_EXIT_CODE);
|
2012-04-06 14:23:13 +00:00
|
|
|
OBJ_RELEASE(caddy);
|
|
|
|
return ;
|
2009-08-13 16:08:43 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
/* if something was found in rankfile, we use that as our global
|
|
|
|
* pool - set it and we are done
|
|
|
|
*/
|
|
|
|
if (!opal_list_is_empty(&nodes)) {
|
|
|
|
/* store the results in the global resource pool - this removes the
|
|
|
|
* list items
|
|
|
|
*/
|
|
|
|
if (ORTE_SUCCESS != (rc = orte_ras_base_node_insert(&nodes, jdata))) {
|
|
|
|
ORTE_ERROR_LOG(rc);
|
As per the RFC, bring in the ORTE async progress code and the rewrite of OOB:
*** THIS RFC INCLUDES A MINOR CHANGE TO THE MPI-RTE INTERFACE ***
Note: during the course of this work, it was necessary to completely separate the MPI and RTE progress engines. There were multiple places in the MPI layer where ORTE_WAIT_FOR_COMPLETION was being used. A new OMPI_WAIT_FOR_COMPLETION macro was created (defined in ompi/mca/rte/rte.h) that simply cycles across opal_progress until the provided flag becomes false. Places where the MPI layer blocked waiting for RTE to complete an event have been modified to use this macro.
***************************************************************************************
I am reissuing this RFC because of the time that has passed since its original release. Since its initial release and review, I have debugged it further to ensure it fully supports tests like loop_spawn. It therefore seems ready for merge back to the trunk. Given its prior review, I have set the timeout for one week.
The code is in https://bitbucket.org/rhc/ompi-oob2
WHAT: Rewrite of ORTE OOB
WHY: Support asynchronous progress and a host of other features
WHEN: Wed, August 21
SYNOPSIS:
The current OOB has served us well, but a number of limitations have been identified over the years. Specifically:
* it is only progressed when called via opal_progress, which can lead to hangs or recursive calls into libevent (which is not supported by that code)
* we've had issues when multiple NICs are available as the code doesn't "shift" messages between transports - thus, all nodes had to be available via the same TCP interface.
* the OOB "unloads" incoming opal_buffer_t objects during the transmission, thus preventing use of OBJ_RETAIN in the code when repeatedly sending the same message to multiple recipients
* there is no failover mechanism across NICs - if the selected NIC (or its attached switch) fails, we are forced to abort
* only one transport (i.e., component) can be "active"
The revised OOB resolves these problems:
* async progress is used for all application processes, with the progress thread blocking in the event library
* each available TCP NIC is supported by its own TCP module. The ability to asynchronously progress each module independently is provided, but not enabled by default (a runtime MCA parameter turns it "on")
* multi-address TCP NICs (e.g., a NIC with both an IPv4 and IPv6 address, or with virtual interfaces) are supported - reachability is determined by comparing the contact info for a peer against all addresses within the range covered by the address/mask pairs for the NIC.
* a message that arrives on one TCP NIC is automatically shifted to whatever NIC that is connected to the next "hop" if that peer cannot be reached by the incoming NIC. If no TCP module will reach the peer, then the OOB attempts to send the message via all other available components - if none can reach the peer, then an "error" is reported back to the RML, which then calls the errmgr for instructions.
* opal_buffer_t now conforms to standard object rules re OBJ_RETAIN as we no longer "unload" the incoming object
* NIC failure is reported to the TCP component, which then tries to resend the message across any other available TCP NIC. If that doesn't work, then the message is given back to the OOB base to try using other components. If all that fails, then the error is reported to the RML, which reports to the errmgr for instructions
* obviously from the above, multiple OOB components (e.g., TCP and UD) can be active in parallel
* the matching code has been moved to the RML (and out of the OOB/TCP component) so it is independent of transport
* routing is done by the individual OOB modules (as opposed to the RML). Thus, both routed and non-routed transports can simultaneously be active
* all blocking send/recv APIs have been removed. Everything operates asynchronously.
KNOWN LIMITATIONS:
* although provision is made for component failover as described above, the code for doing so has not been fully implemented yet. At the moment, if all connections for a given peer fail, the errmgr is notified of a "lost connection", which by default results in termination of the job if it was a lifeline
* the IPv6 code is present and compiles, but is not complete. Since the current IPv6 support in the OOB doesn't work anyway, I don't consider this a blocker
* routing is performed at the individual module level, yet the active routed component is selected on a global basis. We probably should update that to reflect that different transports may need/choose to route in different ways
* obviously, not every error path has been tested nor necessarily covered
* determining abnormal termination is more challenging than in the old code as we now potentially have multiple ways of connecting to a process. Ideally, we would declare "connection failed" when *all* transports can no longer reach the process, but that requires some additional (possibly complex) code. For now, the code replicates the old behavior only somewhat modified - i.e., if a module sees its connection fail, it checks to see if it is a lifeline. If so, it notifies the errmgr that the lifeline is lost - otherwise, it notifies the errmgr that a non-lifeline connection was lost.
* reachability is determined solely on the basis of a shared subnet address/mask - more sophisticated algorithms (e.g., the one used in the tcp btl) are required to handle routing via gateways
* the RML needs to assign sequence numbers to each message on a per-peer basis. The receiving RML will then deliver messages in order, thus preventing out-of-order messaging in the case where messages travel across different transports or a message needs to be redirected/resent due to failure of a NIC
This commit was SVN r29058.
2013-08-22 16:37:40 +00:00
|
|
|
ORTE_FORCED_TERMINATE(ORTE_ERROR_DEFAULT_EXIT_CODE);
|
2012-04-06 14:23:13 +00:00
|
|
|
OBJ_RELEASE(caddy);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
/* rankfile is considered equivalent to an RM allocation */
|
|
|
|
if (!(ORTE_MAPPING_SUBSCRIBE_GIVEN & ORTE_GET_MAPPING_DIRECTIVE(orte_rmaps_base.mapping))) {
|
|
|
|
ORTE_SET_MAPPING_DIRECTIVE(orte_rmaps_base.mapping, ORTE_MAPPING_NO_OVERSUBSCRIBE);
|
2009-08-13 16:08:43 +00:00
|
|
|
}
|
|
|
|
/* cleanup */
|
|
|
|
OBJ_DESTRUCT(&nodes);
|
|
|
|
goto DISPLAY;
|
|
|
|
}
|
2015-06-23 20:59:57 -07:00
|
|
|
|
|
|
|
|
2013-03-27 21:14:43 +00:00
|
|
|
OPAL_OUTPUT_VERBOSE((5, orte_ras_base_framework.framework_output,
|
2009-08-13 16:08:43 +00:00
|
|
|
"%s ras:base:allocate nothing found in rankfile - inserting current node",
|
2009-03-05 21:50:47 +00:00
|
|
|
ORTE_NAME_PRINT(ORTE_PROC_MY_NAME)));
|
2015-06-23 20:59:57 -07:00
|
|
|
|
2012-04-06 14:23:13 +00:00
|
|
|
addlocal:
|
2008-02-28 01:57:57 +00:00
|
|
|
/* if nothing was found by any of the above methods, then we have no
|
|
|
|
* earthly idea what to do - so just add the local host
|
|
|
|
*/
|
|
|
|
node = OBJ_NEW(orte_node_t);
|
|
|
|
if (NULL == node) {
|
|
|
|
ORTE_ERROR_LOG(ORTE_ERR_OUT_OF_RESOURCE);
|
|
|
|
OBJ_DESTRUCT(&nodes);
|
As per the RFC, bring in the ORTE async progress code and the rewrite of OOB:
*** THIS RFC INCLUDES A MINOR CHANGE TO THE MPI-RTE INTERFACE ***
Note: during the course of this work, it was necessary to completely separate the MPI and RTE progress engines. There were multiple places in the MPI layer where ORTE_WAIT_FOR_COMPLETION was being used. A new OMPI_WAIT_FOR_COMPLETION macro was created (defined in ompi/mca/rte/rte.h) that simply cycles across opal_progress until the provided flag becomes false. Places where the MPI layer blocked waiting for RTE to complete an event have been modified to use this macro.
***************************************************************************************
I am reissuing this RFC because of the time that has passed since its original release. Since its initial release and review, I have debugged it further to ensure it fully supports tests like loop_spawn. It therefore seems ready for merge back to the trunk. Given its prior review, I have set the timeout for one week.
The code is in https://bitbucket.org/rhc/ompi-oob2
WHAT: Rewrite of ORTE OOB
WHY: Support asynchronous progress and a host of other features
WHEN: Wed, August 21
SYNOPSIS:
The current OOB has served us well, but a number of limitations have been identified over the years. Specifically:
* it is only progressed when called via opal_progress, which can lead to hangs or recursive calls into libevent (which is not supported by that code)
* we've had issues when multiple NICs are available as the code doesn't "shift" messages between transports - thus, all nodes had to be available via the same TCP interface.
* the OOB "unloads" incoming opal_buffer_t objects during the transmission, thus preventing use of OBJ_RETAIN in the code when repeatedly sending the same message to multiple recipients
* there is no failover mechanism across NICs - if the selected NIC (or its attached switch) fails, we are forced to abort
* only one transport (i.e., component) can be "active"
The revised OOB resolves these problems:
* async progress is used for all application processes, with the progress thread blocking in the event library
* each available TCP NIC is supported by its own TCP module. The ability to asynchronously progress each module independently is provided, but not enabled by default (a runtime MCA parameter turns it "on")
* multi-address TCP NICs (e.g., a NIC with both an IPv4 and IPv6 address, or with virtual interfaces) are supported - reachability is determined by comparing the contact info for a peer against all addresses within the range covered by the address/mask pairs for the NIC.
* a message that arrives on one TCP NIC is automatically shifted to whatever NIC that is connected to the next "hop" if that peer cannot be reached by the incoming NIC. If no TCP module will reach the peer, then the OOB attempts to send the message via all other available components - if none can reach the peer, then an "error" is reported back to the RML, which then calls the errmgr for instructions.
* opal_buffer_t now conforms to standard object rules re OBJ_RETAIN as we no longer "unload" the incoming object
* NIC failure is reported to the TCP component, which then tries to resend the message across any other available TCP NIC. If that doesn't work, then the message is given back to the OOB base to try using other components. If all that fails, then the error is reported to the RML, which reports to the errmgr for instructions
* obviously from the above, multiple OOB components (e.g., TCP and UD) can be active in parallel
* the matching code has been moved to the RML (and out of the OOB/TCP component) so it is independent of transport
* routing is done by the individual OOB modules (as opposed to the RML). Thus, both routed and non-routed transports can simultaneously be active
* all blocking send/recv APIs have been removed. Everything operates asynchronously.
KNOWN LIMITATIONS:
* although provision is made for component failover as described above, the code for doing so has not been fully implemented yet. At the moment, if all connections for a given peer fail, the errmgr is notified of a "lost connection", which by default results in termination of the job if it was a lifeline
* the IPv6 code is present and compiles, but is not complete. Since the current IPv6 support in the OOB doesn't work anyway, I don't consider this a blocker
* routing is performed at the individual module level, yet the active routed component is selected on a global basis. We probably should update that to reflect that different transports may need/choose to route in different ways
* obviously, not every error path has been tested nor necessarily covered
* determining abnormal termination is more challenging than in the old code as we now potentially have multiple ways of connecting to a process. Ideally, we would declare "connection failed" when *all* transports can no longer reach the process, but that requires some additional (possibly complex) code. For now, the code replicates the old behavior only somewhat modified - i.e., if a module sees its connection fail, it checks to see if it is a lifeline. If so, it notifies the errmgr that the lifeline is lost - otherwise, it notifies the errmgr that a non-lifeline connection was lost.
* reachability is determined solely on the basis of a shared subnet address/mask - more sophisticated algorithms (e.g., the one used in the tcp btl) are required to handle routing via gateways
* the RML needs to assign sequence numbers to each message on a per-peer basis. The receiving RML will then deliver messages in order, thus preventing out-of-order messaging in the case where messages travel across different transports or a message needs to be redirected/resent due to failure of a NIC
This commit was SVN r29058.
2013-08-22 16:37:40 +00:00
|
|
|
ORTE_FORCED_TERMINATE(ORTE_ERROR_DEFAULT_EXIT_CODE);
|
2012-04-06 14:23:13 +00:00
|
|
|
OBJ_RELEASE(caddy);
|
|
|
|
return;
|
2006-10-17 16:06:17 +00:00
|
|
|
}
|
2009-03-05 21:56:03 +00:00
|
|
|
/* use the same name we got in orte_process_info so we avoid confusion in
|
2008-02-28 01:57:57 +00:00
|
|
|
* the session directories
|
|
|
|
*/
|
2009-03-05 21:56:03 +00:00
|
|
|
node->name = strdup(orte_process_info.nodename);
|
2008-02-28 01:57:57 +00:00
|
|
|
node->state = ORTE_NODE_STATE_UP;
|
|
|
|
node->slots_inuse = 0;
|
|
|
|
node->slots_max = 0;
|
|
|
|
node->slots = 1;
|
|
|
|
opal_list_append(&nodes, &node->super);
|
2015-06-23 20:59:57 -07:00
|
|
|
|
2008-02-28 01:57:57 +00:00
|
|
|
/* store the results in the global resource pool - this removes the
|
|
|
|
* list items
|
|
|
|
*/
|
|
|
|
if (ORTE_SUCCESS != (rc = orte_ras_base_node_insert(&nodes, jdata))) {
|
|
|
|
ORTE_ERROR_LOG(rc);
|
|
|
|
OBJ_DESTRUCT(&nodes);
|
As per the RFC, bring in the ORTE async progress code and the rewrite of OOB:
*** THIS RFC INCLUDES A MINOR CHANGE TO THE MPI-RTE INTERFACE ***
Note: during the course of this work, it was necessary to completely separate the MPI and RTE progress engines. There were multiple places in the MPI layer where ORTE_WAIT_FOR_COMPLETION was being used. A new OMPI_WAIT_FOR_COMPLETION macro was created (defined in ompi/mca/rte/rte.h) that simply cycles across opal_progress until the provided flag becomes false. Places where the MPI layer blocked waiting for RTE to complete an event have been modified to use this macro.
***************************************************************************************
I am reissuing this RFC because of the time that has passed since its original release. Since its initial release and review, I have debugged it further to ensure it fully supports tests like loop_spawn. It therefore seems ready for merge back to the trunk. Given its prior review, I have set the timeout for one week.
The code is in https://bitbucket.org/rhc/ompi-oob2
WHAT: Rewrite of ORTE OOB
WHY: Support asynchronous progress and a host of other features
WHEN: Wed, August 21
SYNOPSIS:
The current OOB has served us well, but a number of limitations have been identified over the years. Specifically:
* it is only progressed when called via opal_progress, which can lead to hangs or recursive calls into libevent (which is not supported by that code)
* we've had issues when multiple NICs are available as the code doesn't "shift" messages between transports - thus, all nodes had to be available via the same TCP interface.
* the OOB "unloads" incoming opal_buffer_t objects during the transmission, thus preventing use of OBJ_RETAIN in the code when repeatedly sending the same message to multiple recipients
* there is no failover mechanism across NICs - if the selected NIC (or its attached switch) fails, we are forced to abort
* only one transport (i.e., component) can be "active"
The revised OOB resolves these problems:
* async progress is used for all application processes, with the progress thread blocking in the event library
* each available TCP NIC is supported by its own TCP module. The ability to asynchronously progress each module independently is provided, but not enabled by default (a runtime MCA parameter turns it "on")
* multi-address TCP NICs (e.g., a NIC with both an IPv4 and IPv6 address, or with virtual interfaces) are supported - reachability is determined by comparing the contact info for a peer against all addresses within the range covered by the address/mask pairs for the NIC.
* a message that arrives on one TCP NIC is automatically shifted to whatever NIC that is connected to the next "hop" if that peer cannot be reached by the incoming NIC. If no TCP module will reach the peer, then the OOB attempts to send the message via all other available components - if none can reach the peer, then an "error" is reported back to the RML, which then calls the errmgr for instructions.
* opal_buffer_t now conforms to standard object rules re OBJ_RETAIN as we no longer "unload" the incoming object
* NIC failure is reported to the TCP component, which then tries to resend the message across any other available TCP NIC. If that doesn't work, then the message is given back to the OOB base to try using other components. If all that fails, then the error is reported to the RML, which reports to the errmgr for instructions
* obviously from the above, multiple OOB components (e.g., TCP and UD) can be active in parallel
* the matching code has been moved to the RML (and out of the OOB/TCP component) so it is independent of transport
* routing is done by the individual OOB modules (as opposed to the RML). Thus, both routed and non-routed transports can simultaneously be active
* all blocking send/recv APIs have been removed. Everything operates asynchronously.
KNOWN LIMITATIONS:
* although provision is made for component failover as described above, the code for doing so has not been fully implemented yet. At the moment, if all connections for a given peer fail, the errmgr is notified of a "lost connection", which by default results in termination of the job if it was a lifeline
* the IPv6 code is present and compiles, but is not complete. Since the current IPv6 support in the OOB doesn't work anyway, I don't consider this a blocker
* routing is performed at the individual module level, yet the active routed component is selected on a global basis. We probably should update that to reflect that different transports may need/choose to route in different ways
* obviously, not every error path has been tested nor necessarily covered
* determining abnormal termination is more challenging than in the old code as we now potentially have multiple ways of connecting to a process. Ideally, we would declare "connection failed" when *all* transports can no longer reach the process, but that requires some additional (possibly complex) code. For now, the code replicates the old behavior only somewhat modified - i.e., if a module sees its connection fail, it checks to see if it is a lifeline. If so, it notifies the errmgr that the lifeline is lost - otherwise, it notifies the errmgr that a non-lifeline connection was lost.
* reachability is determined solely on the basis of a shared subnet address/mask - more sophisticated algorithms (e.g., the one used in the tcp btl) are required to handle routing via gateways
* the RML needs to assign sequence numbers to each message on a per-peer basis. The receiving RML will then deliver messages in order, thus preventing out-of-order messaging in the case where messages travel across different transports or a message needs to be redirected/resent due to failure of a NIC
This commit was SVN r29058.
2013-08-22 16:37:40 +00:00
|
|
|
ORTE_FORCED_TERMINATE(ORTE_ERROR_DEFAULT_EXIT_CODE);
|
2012-04-06 14:23:13 +00:00
|
|
|
OBJ_RELEASE(caddy);
|
|
|
|
return;
|
2008-02-28 01:57:57 +00:00
|
|
|
}
|
|
|
|
OBJ_DESTRUCT(&nodes);
|
2008-04-21 20:28:59 +00:00
|
|
|
|
2012-04-06 14:23:13 +00:00
|
|
|
DISPLAY:
|
|
|
|
/* shall we display the results? */
|
2013-03-27 21:14:43 +00:00
|
|
|
if (4 < opal_output_get_verbosity(orte_ras_base_framework.framework_output)) {
|
If (and only if) a user requests, set the default number of slots on any node to the number of objects of the specified type. This *only* takes effect in an unmanaged environment - i.e., if an external resource manager assigns us a number of slots, then that is what we use. However, if we are using a hostfile, then the user may or may not have given us a value for the number of slots on each node.
For those nodes (and *only* those nodes) where the user does *not* specify a slot count, we will set the number of slots according to their direction: either to the number of cores, numas, sockets, or hwthreads. Otherwise, the slot count is set to 1.
Note that the default behavior remains unchanged: in the absence of any value for #slots, and in the absence of any directive to set #slots, we will set #slots=1.
This commit was SVN r27236.
2012-09-04 20:58:26 +00:00
|
|
|
orte_ras_base_display_alloc();
|
2012-04-06 14:23:13 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
next_state:
|
2009-09-09 17:47:58 +00:00
|
|
|
/* are we to report this event? */
|
|
|
|
if (orte_report_events) {
|
|
|
|
if (ORTE_SUCCESS != (rc = orte_util_comm_report_event(ORTE_COMM_EVENT_ALLOCATE))) {
|
|
|
|
ORTE_ERROR_LOG(rc);
|
As per the RFC, bring in the ORTE async progress code and the rewrite of OOB:
*** THIS RFC INCLUDES A MINOR CHANGE TO THE MPI-RTE INTERFACE ***
Note: during the course of this work, it was necessary to completely separate the MPI and RTE progress engines. There were multiple places in the MPI layer where ORTE_WAIT_FOR_COMPLETION was being used. A new OMPI_WAIT_FOR_COMPLETION macro was created (defined in ompi/mca/rte/rte.h) that simply cycles across opal_progress until the provided flag becomes false. Places where the MPI layer blocked waiting for RTE to complete an event have been modified to use this macro.
***************************************************************************************
I am reissuing this RFC because of the time that has passed since its original release. Since its initial release and review, I have debugged it further to ensure it fully supports tests like loop_spawn. It therefore seems ready for merge back to the trunk. Given its prior review, I have set the timeout for one week.
The code is in https://bitbucket.org/rhc/ompi-oob2
WHAT: Rewrite of ORTE OOB
WHY: Support asynchronous progress and a host of other features
WHEN: Wed, August 21
SYNOPSIS:
The current OOB has served us well, but a number of limitations have been identified over the years. Specifically:
* it is only progressed when called via opal_progress, which can lead to hangs or recursive calls into libevent (which is not supported by that code)
* we've had issues when multiple NICs are available as the code doesn't "shift" messages between transports - thus, all nodes had to be available via the same TCP interface.
* the OOB "unloads" incoming opal_buffer_t objects during the transmission, thus preventing use of OBJ_RETAIN in the code when repeatedly sending the same message to multiple recipients
* there is no failover mechanism across NICs - if the selected NIC (or its attached switch) fails, we are forced to abort
* only one transport (i.e., component) can be "active"
The revised OOB resolves these problems:
* async progress is used for all application processes, with the progress thread blocking in the event library
* each available TCP NIC is supported by its own TCP module. The ability to asynchronously progress each module independently is provided, but not enabled by default (a runtime MCA parameter turns it "on")
* multi-address TCP NICs (e.g., a NIC with both an IPv4 and IPv6 address, or with virtual interfaces) are supported - reachability is determined by comparing the contact info for a peer against all addresses within the range covered by the address/mask pairs for the NIC.
* a message that arrives on one TCP NIC is automatically shifted to whatever NIC that is connected to the next "hop" if that peer cannot be reached by the incoming NIC. If no TCP module will reach the peer, then the OOB attempts to send the message via all other available components - if none can reach the peer, then an "error" is reported back to the RML, which then calls the errmgr for instructions.
* opal_buffer_t now conforms to standard object rules re OBJ_RETAIN as we no longer "unload" the incoming object
* NIC failure is reported to the TCP component, which then tries to resend the message across any other available TCP NIC. If that doesn't work, then the message is given back to the OOB base to try using other components. If all that fails, then the error is reported to the RML, which reports to the errmgr for instructions
* obviously from the above, multiple OOB components (e.g., TCP and UD) can be active in parallel
* the matching code has been moved to the RML (and out of the OOB/TCP component) so it is independent of transport
* routing is done by the individual OOB modules (as opposed to the RML). Thus, both routed and non-routed transports can simultaneously be active
* all blocking send/recv APIs have been removed. Everything operates asynchronously.
KNOWN LIMITATIONS:
* although provision is made for component failover as described above, the code for doing so has not been fully implemented yet. At the moment, if all connections for a given peer fail, the errmgr is notified of a "lost connection", which by default results in termination of the job if it was a lifeline
* the IPv6 code is present and compiles, but is not complete. Since the current IPv6 support in the OOB doesn't work anyway, I don't consider this a blocker
* routing is performed at the individual module level, yet the active routed component is selected on a global basis. We probably should update that to reflect that different transports may need/choose to route in different ways
* obviously, not every error path has been tested nor necessarily covered
* determining abnormal termination is more challenging than in the old code as we now potentially have multiple ways of connecting to a process. Ideally, we would declare "connection failed" when *all* transports can no longer reach the process, but that requires some additional (possibly complex) code. For now, the code replicates the old behavior only somewhat modified - i.e., if a module sees its connection fail, it checks to see if it is a lifeline. If so, it notifies the errmgr that the lifeline is lost - otherwise, it notifies the errmgr that a non-lifeline connection was lost.
* reachability is determined solely on the basis of a shared subnet address/mask - more sophisticated algorithms (e.g., the one used in the tcp btl) are required to handle routing via gateways
* the RML needs to assign sequence numbers to each message on a per-peer basis. The receiving RML will then deliver messages in order, thus preventing out-of-order messaging in the case where messages travel across different transports or a message needs to be redirected/resent due to failure of a NIC
This commit was SVN r29058.
2013-08-22 16:37:40 +00:00
|
|
|
ORTE_FORCED_TERMINATE(ORTE_ERROR_DEFAULT_EXIT_CODE);
|
2012-04-06 14:23:13 +00:00
|
|
|
OBJ_RELEASE(caddy);
|
2009-09-09 17:47:58 +00:00
|
|
|
}
|
|
|
|
}
|
2015-06-23 20:59:57 -07:00
|
|
|
|
2012-04-06 14:23:13 +00:00
|
|
|
/* set total slots alloc */
|
|
|
|
jdata->total_slots_alloc = orte_ras_base.total_slots_alloc;
|
|
|
|
|
|
|
|
/* set the job state to the next position */
|
2012-08-03 16:30:05 +00:00
|
|
|
ORTE_ACTIVATE_JOB_STATE(jdata, ORTE_JOB_STATE_ALLOCATION_COMPLETE);
|
2012-04-06 14:23:13 +00:00
|
|
|
|
|
|
|
/* cleanup */
|
|
|
|
OBJ_RELEASE(caddy);
|
2009-07-14 14:34:11 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
int orte_ras_base_add_hosts(orte_job_t *jdata)
|
|
|
|
{
|
|
|
|
int rc;
|
|
|
|
opal_list_t nodes;
|
|
|
|
int i;
|
|
|
|
orte_app_context_t *app;
|
2014-04-30 22:26:18 +00:00
|
|
|
orte_node_t *node;
|
2014-06-01 16:14:10 +00:00
|
|
|
char *hosts;
|
2009-07-14 14:34:11 +00:00
|
|
|
|
|
|
|
/* construct a list to hold the results */
|
|
|
|
OBJ_CONSTRUCT(&nodes, opal_list_t);
|
2015-06-23 20:59:57 -07:00
|
|
|
|
2009-07-14 14:34:11 +00:00
|
|
|
/* Individual add-hostfile names, if given, are included
|
|
|
|
* in the app_contexts for this job. We therefore need to
|
|
|
|
* retrieve the app_contexts for the job, and then cycle
|
|
|
|
* through them to see if anything is there. The parser will
|
|
|
|
* add the nodes found in each add-hostfile to our list - i.e.,
|
|
|
|
* the resulting list contains the UNION of all nodes specified
|
|
|
|
* in add-hostfiles from across all app_contexts
|
|
|
|
*
|
|
|
|
* Note that any relative node syntax found in the add-hostfiles will
|
|
|
|
* generate an error in this scenario, so only non-relative syntax
|
|
|
|
* can be present
|
|
|
|
*/
|
2015-06-23 20:59:57 -07:00
|
|
|
|
2009-07-14 14:34:11 +00:00
|
|
|
for (i=0; i < jdata->apps->size; i++) {
|
|
|
|
if (NULL == (app = (orte_app_context_t*)opal_pointer_array_get_item(jdata->apps, i))) {
|
|
|
|
continue;
|
2008-06-04 20:53:12 +00:00
|
|
|
}
|
2014-06-01 16:14:10 +00:00
|
|
|
if (orte_get_attribute(&app->attributes, ORTE_APP_ADD_HOSTFILE, (void**)&hosts, OPAL_STRING)) {
|
2013-03-27 21:14:43 +00:00
|
|
|
OPAL_OUTPUT_VERBOSE((5, orte_ras_base_framework.framework_output,
|
2009-07-14 14:34:11 +00:00
|
|
|
"%s ras:base:add_hosts checking add-hostfile %s",
|
2014-06-01 16:14:10 +00:00
|
|
|
ORTE_NAME_PRINT(ORTE_PROC_MY_NAME), hosts));
|
2015-06-23 20:59:57 -07:00
|
|
|
|
2009-07-14 14:34:11 +00:00
|
|
|
/* hostfile was specified - parse it and add it to the list */
|
2014-06-01 16:14:10 +00:00
|
|
|
if (ORTE_SUCCESS != (rc = orte_util_add_hostfile_nodes(&nodes, hosts))) {
|
2009-07-14 14:34:11 +00:00
|
|
|
ORTE_ERROR_LOG(rc);
|
|
|
|
OBJ_DESTRUCT(&nodes);
|
2014-06-01 16:14:10 +00:00
|
|
|
free(hosts);
|
2009-07-14 14:34:11 +00:00
|
|
|
return rc;
|
2008-04-20 02:25:45 +00:00
|
|
|
}
|
2012-10-18 00:40:44 +00:00
|
|
|
/* now indicate that this app is to run across it */
|
2014-06-01 16:14:10 +00:00
|
|
|
orte_set_attribute(&app->attributes, ORTE_APP_HOSTFILE, ORTE_ATTR_LOCAL, (void**)hosts, OPAL_STRING);
|
|
|
|
orte_remove_attribute(&app->attributes, ORTE_APP_ADD_HOSTFILE);
|
|
|
|
free(hosts);
|
2009-07-14 14:34:11 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/* We next check for and add any add-host options. Note this is
|
|
|
|
* a -little- different than dash-host in that (a) we add these
|
|
|
|
* nodes to the global pool regardless of what may already be there,
|
|
|
|
* and (b) as a result, any job and/or app_context can access them.
|
|
|
|
*
|
|
|
|
* Note that any relative node syntax found in the add-host lists will
|
|
|
|
* generate an error in this scenario, so only non-relative syntax
|
|
|
|
* can be present
|
|
|
|
*/
|
|
|
|
for (i=0; i < jdata->apps->size; i++) {
|
|
|
|
if (NULL == (app = (orte_app_context_t*)opal_pointer_array_get_item(jdata->apps, i))) {
|
|
|
|
continue;
|
|
|
|
}
|
2014-06-01 16:14:10 +00:00
|
|
|
if (orte_get_attribute(&app->attributes, ORTE_APP_ADD_HOST, (void**)&hosts, OPAL_STRING)) {
|
|
|
|
opal_output_verbose(5, orte_ras_base_framework.framework_output,
|
|
|
|
"%s ras:base:add_hosts checking add-host %s",
|
|
|
|
ORTE_NAME_PRINT(ORTE_PROC_MY_NAME), hosts);
|
|
|
|
if (ORTE_SUCCESS != (rc = orte_util_add_dash_host_nodes(&nodes, hosts))) {
|
2009-07-14 14:34:11 +00:00
|
|
|
ORTE_ERROR_LOG(rc);
|
|
|
|
OBJ_DESTRUCT(&nodes);
|
2014-06-01 16:14:10 +00:00
|
|
|
free(hosts);
|
2009-07-14 14:34:11 +00:00
|
|
|
return rc;
|
2008-06-04 20:53:12 +00:00
|
|
|
}
|
2012-10-18 00:40:44 +00:00
|
|
|
/* now indicate that this app is to run across them */
|
2014-06-01 16:14:10 +00:00
|
|
|
orte_set_attribute(&app->attributes, ORTE_APP_DASH_HOST, ORTE_ATTR_LOCAL, hosts, OPAL_STRING);
|
|
|
|
orte_remove_attribute(&app->attributes, ORTE_APP_ADD_HOST);
|
|
|
|
free(hosts);
|
2008-06-04 20:53:12 +00:00
|
|
|
}
|
2009-07-14 14:34:11 +00:00
|
|
|
}
|
2015-06-23 20:59:57 -07:00
|
|
|
|
2009-07-14 14:34:11 +00:00
|
|
|
/* if something was found, we add that to our global pool */
|
|
|
|
if (!opal_list_is_empty(&nodes)) {
|
2014-04-30 22:26:18 +00:00
|
|
|
/* mark all the nodes as "added" */
|
|
|
|
OPAL_LIST_FOREACH(node, &nodes, orte_node_t) {
|
|
|
|
node->state = ORTE_NODE_STATE_ADDED;
|
|
|
|
}
|
2009-07-14 14:34:11 +00:00
|
|
|
/* store the results in the global resource pool - this removes the
|
|
|
|
* list items
|
|
|
|
*/
|
|
|
|
if (ORTE_SUCCESS != (rc = orte_ras_base_node_insert(&nodes, jdata))) {
|
|
|
|
ORTE_ERROR_LOG(rc);
|
2008-04-20 02:25:45 +00:00
|
|
|
}
|
2009-07-14 14:34:11 +00:00
|
|
|
/* cleanup */
|
|
|
|
OBJ_DESTRUCT(&nodes);
|
2008-04-20 02:25:45 +00:00
|
|
|
}
|
2015-06-23 20:59:57 -07:00
|
|
|
|
2009-07-14 14:34:11 +00:00
|
|
|
/* shall we display the results? */
|
2013-03-27 21:14:43 +00:00
|
|
|
if (0 < opal_output_get_verbosity(orte_ras_base_framework.framework_output)) {
|
If (and only if) a user requests, set the default number of slots on any node to the number of objects of the specified type. This *only* takes effect in an unmanaged environment - i.e., if an external resource manager assigns us a number of slots, then that is what we use. However, if we are using a hostfile, then the user may or may not have given us a value for the number of slots on each node.
For those nodes (and *only* those nodes) where the user does *not* specify a slot count, we will set the number of slots according to their direction: either to the number of cores, numas, sockets, or hwthreads. Otherwise, the slot count is set to 1.
Note that the default behavior remains unchanged: in the absence of any value for #slots, and in the absence of any directive to set #slots, we will set #slots=1.
This commit was SVN r27236.
2012-09-04 20:58:26 +00:00
|
|
|
orte_ras_base_display_alloc();
|
2009-07-14 14:34:11 +00:00
|
|
|
}
|
2015-06-23 20:59:57 -07:00
|
|
|
|
2009-07-14 14:34:11 +00:00
|
|
|
return ORTE_SUCCESS;
|
2006-10-17 16:06:17 +00:00
|
|
|
}
|