2005-03-14 20:57:21 +00:00
|
|
|
/*
|
2007-03-29 00:50:56 +00:00
|
|
|
* Copyright (c) 2004-2007 The Trustees of Indiana University and Indiana
|
2005-11-05 19:57:48 +00:00
|
|
|
* University Research and Technology
|
|
|
|
* Corporation. All rights reserved.
|
2006-08-23 03:32:36 +00:00
|
|
|
* Copyright (c) 2004-2006 The University of Tennessee and The University
|
2005-11-05 19:57:48 +00:00
|
|
|
* of Tennessee Research Foundation. All rights
|
|
|
|
* reserved.
|
2005-03-14 20:57:21 +00:00
|
|
|
* Copyright (c) 2004-2005 High Performance Computing Center Stuttgart,
|
|
|
|
* University of Stuttgart. All rights reserved.
|
2005-03-24 12:43:37 +00:00
|
|
|
* Copyright (c) 2004-2005 The Regents of the University of California.
|
|
|
|
* All rights reserved.
|
2006-07-04 20:12:35 +00:00
|
|
|
* Copyright (c) 2006 Cisco Systems, Inc. All rights reserved.
|
2005-03-14 20:57:21 +00:00
|
|
|
* $COPYRIGHT$
|
|
|
|
*
|
|
|
|
* Additional copyrights may follow
|
|
|
|
*
|
|
|
|
* $HEADER$
|
|
|
|
*/
|
2006-07-04 20:12:35 +00:00
|
|
|
|
2005-03-14 20:57:21 +00:00
|
|
|
#include "orte_config.h"
|
2006-07-10 14:10:21 +00:00
|
|
|
#include "orte/orte_constants.h"
|
|
|
|
#include "orte/orte_types.h"
|
|
|
|
|
2005-03-14 20:57:21 +00:00
|
|
|
#include <errno.h>
|
2005-12-12 20:04:00 +00:00
|
|
|
#ifdef HAVE_UNISTD_H
|
2005-03-14 20:57:21 +00:00
|
|
|
#include <unistd.h>
|
2005-12-12 20:04:00 +00:00
|
|
|
#endif /* HAVE_UNISTD_H */
|
|
|
|
#ifdef HAVE_STRING_H
|
2005-03-14 20:57:21 +00:00
|
|
|
#include <string.h>
|
2005-12-12 20:04:00 +00:00
|
|
|
#endif /* HAVE_STRING_H */
|
2005-03-14 20:57:21 +00:00
|
|
|
|
2006-07-04 20:12:35 +00:00
|
|
|
#include "opal/mca/base/mca_base_param.h"
|
2005-07-03 23:31:27 +00:00
|
|
|
#include "opal/util/output.h"
|
2006-10-07 15:45:24 +00:00
|
|
|
#include "opal/util/trace.h"
|
2005-09-30 14:30:21 +00:00
|
|
|
#include "opal/util/show_help.h"
|
2005-10-07 22:24:52 +00:00
|
|
|
#include "opal/util/argv.h"
|
2006-07-10 14:10:21 +00:00
|
|
|
|
2006-10-18 20:02:16 +00:00
|
|
|
#include "orte/dss/dss.h"
|
2006-07-10 14:10:21 +00:00
|
|
|
#include "orte/mca/errmgr/errmgr.h"
|
2006-02-12 01:33:29 +00:00
|
|
|
#include "orte/mca/ns/ns.h"
|
|
|
|
#include "orte/mca/gpr/gpr.h"
|
2006-09-14 21:29:51 +00:00
|
|
|
#include "orte/mca/rmgr/rmgr.h"
|
|
|
|
|
|
|
|
#include "orte/mca/rmaps/base/rmaps_private.h"
|
2006-10-07 19:50:12 +00:00
|
|
|
#include "orte/mca/rmaps/base/base.h"
|
2005-03-14 20:57:21 +00:00
|
|
|
#include "rmaps_rr.h"
|
|
|
|
|
|
|
|
|
|
|
|
/*
|
(copied from a mail that has a lengthy description of this commit)
I spoke with Tim about this the other day -- he gave me the green
light to go ahead with this, but it turned into a bigger job than I
thought it would be. I revamped how the default RAS scheduling and
round_robin RMAPS mapping occurs. The previous algorithms were pretty
brain dead, and ignored the "slots" and "max_slots" tokens in
hostfiles. I considered this a big enough problem to fix it for the
beta (because there is currently no way to control where processes are
launched on SMPs).
There's still some more bells and whistles that I'd like to implement,
but there's no hurry, and they can go on the trunk at any time. My
patches below are for what I considered "essential", and do the
following:
- honor the "slots" and "max-slots" tokens in the hostfile (and all
their synonyms), meaning that we allocate/map until we fill slots,
and if there are still more processes to allocate/map, we keep going
until we fill max-slots (i.e., only oversubscribe a node if we have
to).
- offer two different algorithms, currently supported by two new
options to orterun. Remember that there are two parts here -- slot
allocation and process mapping. Slot allocation controls how many
processes we'll be running on a node. After that decision has been
made, process mapping effectively controls where the ranks of
MPI_COMM_WORLD (MCW) are placed. Some of the examples given below
don't make sense unless you remember that there is a difference
between the two (which makes total sense, but you have to think
about it in terms of both things):
1. "-bynode": allocates/maps one process per node in a round-robin
fashion until all slots on the node are taken. If we still have more
processes after all slots are taken, then keep going until all
max-slots are taken. Examples:
- The hostfile:
eddie slots=2 max-slots=4
vogon slots=4 max-slots=8
- orterun -bynode -np 6 -hostfile hostfile a.out
eddie: MCW ranks 0, 2
vogon: MCW ranks 1, 3, 4, 5
- orterun -bynode -np 8 -hostfile hostfile a.out
eddie: MCW ranks 0, 2, 4
vogon: MCW ranks 1, 3, 5, 6, 7
-> the algorithm oversubscribes all nodes "equally" (until each
node's max_slots is hit, of course)
- orterun -bynode -np 12 -hostfile hostfile a.out
eddie: MCW ranks 0, 2, 4, 6
vogon: MCW ranks 1, 3, 5, 7, 8, 9, 10, 11
2. "-byslot" (this is the default if you don't specify -bynode):
greedily takes all available slots on a node for a job before moving
on to the next node. If we still have processes to allocate/schedule,
then oversubscribe all nodes equally (i.e., go round robin on all
nodes until each node's max_slots is hit). Examples:
- The hostfile
eddie slots=2 max-slots=4
vogon slots=4 max-slots=8
- orterun -np 6 -hostfile hostfile a.out
eddie: MCW ranks 0, 1
vogon: MCW ranks 2, 3, 4, 5
- orterun -np 8 -hostfile hostfile a.out
eddie: MCW ranks 0, 1, 2
vogon: MCW ranks 3, 4, 5, 6, 7
-> the algorithm oversubscribes all nodes "equally" (until max_slots
is hit)
- orterun -np 12 -hostfile hostfile a.out
eddie: MCW ranks 0, 1, 2, 3
vogon: MCW ranks 4, 5, 6, 7, 8, 9, 10, 11
The above examples are fairly contrived, and it's not clear from them
that you can get different allocation answers in all cases (the
mapping differences are obvious). Consider the following allocation
example:
- The hostfile
eddie count=4
vogon count=4
earth count=4
deep-thought count=4
- orterun -np 8 -hostfile hostfile a.out
eddie: 4 slots will be allocated
vogon: 4 slots will be allocated
earth: no slots allocated
deep-thought: no slots allocated
- orterun -bynode -np 8 -hostfile hostfile a.out
eddie: 2 slots will be allocated
vogon: 2 slots will be allocated
earth: 2 slots will be allocated
deep-thought: 2 slots will be allocated
This commit was SVN r5894.
2005-05-31 16:36:53 +00:00
|
|
|
* Local variable
|
2005-03-14 20:57:21 +00:00
|
|
|
*/
|
2005-07-03 16:22:16 +00:00
|
|
|
static opal_list_item_t *cur_node_item = NULL;
|
2006-07-10 14:10:21 +00:00
|
|
|
static opal_list_t fully_used_nodes;
|
2006-12-12 00:54:05 +00:00
|
|
|
static orte_std_cntr_t num_per_node;
|
(copied from a mail that has a lengthy description of this commit)
I spoke with Tim about this the other day -- he gave me the green
light to go ahead with this, but it turned into a bigger job than I
thought it would be. I revamped how the default RAS scheduling and
round_robin RMAPS mapping occurs. The previous algorithms were pretty
brain dead, and ignored the "slots" and "max_slots" tokens in
hostfiles. I considered this a big enough problem to fix it for the
beta (because there is currently no way to control where processes are
launched on SMPs).
There's still some more bells and whistles that I'd like to implement,
but there's no hurry, and they can go on the trunk at any time. My
patches below are for what I considered "essential", and do the
following:
- honor the "slots" and "max-slots" tokens in the hostfile (and all
their synonyms), meaning that we allocate/map until we fill slots,
and if there are still more processes to allocate/map, we keep going
until we fill max-slots (i.e., only oversubscribe a node if we have
to).
- offer two different algorithms, currently supported by two new
options to orterun. Remember that there are two parts here -- slot
allocation and process mapping. Slot allocation controls how many
processes we'll be running on a node. After that decision has been
made, process mapping effectively controls where the ranks of
MPI_COMM_WORLD (MCW) are placed. Some of the examples given below
don't make sense unless you remember that there is a difference
between the two (which makes total sense, but you have to think
about it in terms of both things):
1. "-bynode": allocates/maps one process per node in a round-robin
fashion until all slots on the node are taken. If we still have more
processes after all slots are taken, then keep going until all
max-slots are taken. Examples:
- The hostfile:
eddie slots=2 max-slots=4
vogon slots=4 max-slots=8
- orterun -bynode -np 6 -hostfile hostfile a.out
eddie: MCW ranks 0, 2
vogon: MCW ranks 1, 3, 4, 5
- orterun -bynode -np 8 -hostfile hostfile a.out
eddie: MCW ranks 0, 2, 4
vogon: MCW ranks 1, 3, 5, 6, 7
-> the algorithm oversubscribes all nodes "equally" (until each
node's max_slots is hit, of course)
- orterun -bynode -np 12 -hostfile hostfile a.out
eddie: MCW ranks 0, 2, 4, 6
vogon: MCW ranks 1, 3, 5, 7, 8, 9, 10, 11
2. "-byslot" (this is the default if you don't specify -bynode):
greedily takes all available slots on a node for a job before moving
on to the next node. If we still have processes to allocate/schedule,
then oversubscribe all nodes equally (i.e., go round robin on all
nodes until each node's max_slots is hit). Examples:
- The hostfile
eddie slots=2 max-slots=4
vogon slots=4 max-slots=8
- orterun -np 6 -hostfile hostfile a.out
eddie: MCW ranks 0, 1
vogon: MCW ranks 2, 3, 4, 5
- orterun -np 8 -hostfile hostfile a.out
eddie: MCW ranks 0, 1, 2
vogon: MCW ranks 3, 4, 5, 6, 7
-> the algorithm oversubscribes all nodes "equally" (until max_slots
is hit)
- orterun -np 12 -hostfile hostfile a.out
eddie: MCW ranks 0, 1, 2, 3
vogon: MCW ranks 4, 5, 6, 7, 8, 9, 10, 11
The above examples are fairly contrived, and it's not clear from them
that you can get different allocation answers in all cases (the
mapping differences are obvious). Consider the following allocation
example:
- The hostfile
eddie count=4
vogon count=4
earth count=4
deep-thought count=4
- orterun -np 8 -hostfile hostfile a.out
eddie: 4 slots will be allocated
vogon: 4 slots will be allocated
earth: no slots allocated
deep-thought: no slots allocated
- orterun -bynode -np 8 -hostfile hostfile a.out
eddie: 2 slots will be allocated
vogon: 2 slots will be allocated
earth: 2 slots will be allocated
deep-thought: 2 slots will be allocated
This commit was SVN r5894.
2005-05-31 16:36:53 +00:00
|
|
|
|
|
|
|
|
2007-07-14 15:14:07 +00:00
|
|
|
|
|
|
|
|
|
|
|
static int map_app_by_allocated_ranks(
|
|
|
|
orte_app_context_t* app,
|
|
|
|
orte_job_map_t* map,
|
|
|
|
orte_jobid_t jobid,
|
|
|
|
orte_vpid_t vpid_start,
|
|
|
|
opal_list_t* nodes,
|
|
|
|
opal_list_t* max_used_nodes,
|
|
|
|
opal_list_t* procs,
|
|
|
|
orte_std_cntr_t *num_alloc)
|
|
|
|
{
|
|
|
|
int rc = ORTE_SUCCESS;
|
|
|
|
orte_ras_proc_t *proc;
|
|
|
|
opal_list_item_t *proc_item, *node_item;
|
|
|
|
orte_ras_node_t *node;
|
|
|
|
|
|
|
|
|
|
|
|
for (proc_item = opal_list_get_first(procs);
|
|
|
|
proc_item != opal_list_get_end(procs);
|
|
|
|
proc_item = opal_list_get_next(proc_item)) {
|
|
|
|
proc = (orte_ras_proc_t *)proc_item;
|
|
|
|
if(proc->rank >= vpid_start && proc->rank < (vpid_start + app->num_procs)){
|
|
|
|
for (node_item = opal_list_get_first(nodes);
|
|
|
|
node_item != opal_list_get_end(nodes);
|
|
|
|
node_item = opal_list_get_next(node_item)) {
|
|
|
|
node = (orte_ras_node_t *)node_item;
|
|
|
|
if(0 == strcmp(node->node_name, proc->node_name)){
|
|
|
|
if (ORTE_SUCCESS != (rc = orte_rmaps_base_claim_slot(map, node, jobid, proc->rank, app->idx,
|
|
|
|
nodes, max_used_nodes, false))) {
|
|
|
|
/** if the code is ORTE_ERR_NODE_FULLY_USED, then we know this
|
|
|
|
* really isn't an error - we just need to break from the loop
|
|
|
|
* since the node is fully used up. For now, just don't report
|
|
|
|
* an error
|
|
|
|
*/
|
|
|
|
if (ORTE_ERR_NODE_FULLY_USED != rc) {
|
|
|
|
ORTE_ERROR_LOG(rc);
|
|
|
|
return rc;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
(*num_alloc)++;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
return ORTE_SUCCESS;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
|
(copied from a mail that has a lengthy description of this commit)
I spoke with Tim about this the other day -- he gave me the green
light to go ahead with this, but it turned into a bigger job than I
thought it would be. I revamped how the default RAS scheduling and
round_robin RMAPS mapping occurs. The previous algorithms were pretty
brain dead, and ignored the "slots" and "max_slots" tokens in
hostfiles. I considered this a big enough problem to fix it for the
beta (because there is currently no way to control where processes are
launched on SMPs).
There's still some more bells and whistles that I'd like to implement,
but there's no hurry, and they can go on the trunk at any time. My
patches below are for what I considered "essential", and do the
following:
- honor the "slots" and "max-slots" tokens in the hostfile (and all
their synonyms), meaning that we allocate/map until we fill slots,
and if there are still more processes to allocate/map, we keep going
until we fill max-slots (i.e., only oversubscribe a node if we have
to).
- offer two different algorithms, currently supported by two new
options to orterun. Remember that there are two parts here -- slot
allocation and process mapping. Slot allocation controls how many
processes we'll be running on a node. After that decision has been
made, process mapping effectively controls where the ranks of
MPI_COMM_WORLD (MCW) are placed. Some of the examples given below
don't make sense unless you remember that there is a difference
between the two (which makes total sense, but you have to think
about it in terms of both things):
1. "-bynode": allocates/maps one process per node in a round-robin
fashion until all slots on the node are taken. If we still have more
processes after all slots are taken, then keep going until all
max-slots are taken. Examples:
- The hostfile:
eddie slots=2 max-slots=4
vogon slots=4 max-slots=8
- orterun -bynode -np 6 -hostfile hostfile a.out
eddie: MCW ranks 0, 2
vogon: MCW ranks 1, 3, 4, 5
- orterun -bynode -np 8 -hostfile hostfile a.out
eddie: MCW ranks 0, 2, 4
vogon: MCW ranks 1, 3, 5, 6, 7
-> the algorithm oversubscribes all nodes "equally" (until each
node's max_slots is hit, of course)
- orterun -bynode -np 12 -hostfile hostfile a.out
eddie: MCW ranks 0, 2, 4, 6
vogon: MCW ranks 1, 3, 5, 7, 8, 9, 10, 11
2. "-byslot" (this is the default if you don't specify -bynode):
greedily takes all available slots on a node for a job before moving
on to the next node. If we still have processes to allocate/schedule,
then oversubscribe all nodes equally (i.e., go round robin on all
nodes until each node's max_slots is hit). Examples:
- The hostfile
eddie slots=2 max-slots=4
vogon slots=4 max-slots=8
- orterun -np 6 -hostfile hostfile a.out
eddie: MCW ranks 0, 1
vogon: MCW ranks 2, 3, 4, 5
- orterun -np 8 -hostfile hostfile a.out
eddie: MCW ranks 0, 1, 2
vogon: MCW ranks 3, 4, 5, 6, 7
-> the algorithm oversubscribes all nodes "equally" (until max_slots
is hit)
- orterun -np 12 -hostfile hostfile a.out
eddie: MCW ranks 0, 1, 2, 3
vogon: MCW ranks 4, 5, 6, 7, 8, 9, 10, 11
The above examples are fairly contrived, and it's not clear from them
that you can get different allocation answers in all cases (the
mapping differences are obvious). Consider the following allocation
example:
- The hostfile
eddie count=4
vogon count=4
earth count=4
deep-thought count=4
- orterun -np 8 -hostfile hostfile a.out
eddie: 4 slots will be allocated
vogon: 4 slots will be allocated
earth: no slots allocated
deep-thought: no slots allocated
- orterun -bynode -np 8 -hostfile hostfile a.out
eddie: 2 slots will be allocated
vogon: 2 slots will be allocated
earth: 2 slots will be allocated
deep-thought: 2 slots will be allocated
This commit was SVN r5894.
2005-05-31 16:36:53 +00:00
|
|
|
/*
|
|
|
|
* Create a default mapping for the application, scheduling round
|
|
|
|
* robin by node.
|
|
|
|
*/
|
|
|
|
static int map_app_by_node(
|
2005-08-25 15:42:41 +00:00
|
|
|
orte_app_context_t* app,
|
2006-10-07 15:45:24 +00:00
|
|
|
orte_job_map_t* map,
|
2005-03-14 20:57:21 +00:00
|
|
|
orte_jobid_t jobid,
|
|
|
|
orte_vpid_t vpid_start,
|
2005-10-07 22:24:52 +00:00
|
|
|
opal_list_t* nodes,
|
2007-07-14 15:14:07 +00:00
|
|
|
opal_list_t* max_used_nodes,
|
|
|
|
orte_std_cntr_t num_alloc)
|
2005-03-14 20:57:21 +00:00
|
|
|
{
|
2005-10-08 17:03:12 +00:00
|
|
|
int rc = ORTE_SUCCESS;
|
2005-10-07 22:24:52 +00:00
|
|
|
opal_list_item_t *next;
|
2005-08-11 19:51:50 +00:00
|
|
|
orte_ras_node_t *node;
|
2005-03-14 20:57:21 +00:00
|
|
|
|
2006-10-07 15:45:24 +00:00
|
|
|
OPAL_TRACE(2);
|
|
|
|
|
(copied from a mail that has a lengthy description of this commit)
I spoke with Tim about this the other day -- he gave me the green
light to go ahead with this, but it turned into a bigger job than I
thought it would be. I revamped how the default RAS scheduling and
round_robin RMAPS mapping occurs. The previous algorithms were pretty
brain dead, and ignored the "slots" and "max_slots" tokens in
hostfiles. I considered this a big enough problem to fix it for the
beta (because there is currently no way to control where processes are
launched on SMPs).
There's still some more bells and whistles that I'd like to implement,
but there's no hurry, and they can go on the trunk at any time. My
patches below are for what I considered "essential", and do the
following:
- honor the "slots" and "max-slots" tokens in the hostfile (and all
their synonyms), meaning that we allocate/map until we fill slots,
and if there are still more processes to allocate/map, we keep going
until we fill max-slots (i.e., only oversubscribe a node if we have
to).
- offer two different algorithms, currently supported by two new
options to orterun. Remember that there are two parts here -- slot
allocation and process mapping. Slot allocation controls how many
processes we'll be running on a node. After that decision has been
made, process mapping effectively controls where the ranks of
MPI_COMM_WORLD (MCW) are placed. Some of the examples given below
don't make sense unless you remember that there is a difference
between the two (which makes total sense, but you have to think
about it in terms of both things):
1. "-bynode": allocates/maps one process per node in a round-robin
fashion until all slots on the node are taken. If we still have more
processes after all slots are taken, then keep going until all
max-slots are taken. Examples:
- The hostfile:
eddie slots=2 max-slots=4
vogon slots=4 max-slots=8
- orterun -bynode -np 6 -hostfile hostfile a.out
eddie: MCW ranks 0, 2
vogon: MCW ranks 1, 3, 4, 5
- orterun -bynode -np 8 -hostfile hostfile a.out
eddie: MCW ranks 0, 2, 4
vogon: MCW ranks 1, 3, 5, 6, 7
-> the algorithm oversubscribes all nodes "equally" (until each
node's max_slots is hit, of course)
- orterun -bynode -np 12 -hostfile hostfile a.out
eddie: MCW ranks 0, 2, 4, 6
vogon: MCW ranks 1, 3, 5, 7, 8, 9, 10, 11
2. "-byslot" (this is the default if you don't specify -bynode):
greedily takes all available slots on a node for a job before moving
on to the next node. If we still have processes to allocate/schedule,
then oversubscribe all nodes equally (i.e., go round robin on all
nodes until each node's max_slots is hit). Examples:
- The hostfile
eddie slots=2 max-slots=4
vogon slots=4 max-slots=8
- orterun -np 6 -hostfile hostfile a.out
eddie: MCW ranks 0, 1
vogon: MCW ranks 2, 3, 4, 5
- orterun -np 8 -hostfile hostfile a.out
eddie: MCW ranks 0, 1, 2
vogon: MCW ranks 3, 4, 5, 6, 7
-> the algorithm oversubscribes all nodes "equally" (until max_slots
is hit)
- orterun -np 12 -hostfile hostfile a.out
eddie: MCW ranks 0, 1, 2, 3
vogon: MCW ranks 4, 5, 6, 7, 8, 9, 10, 11
The above examples are fairly contrived, and it's not clear from them
that you can get different allocation answers in all cases (the
mapping differences are obvious). Consider the following allocation
example:
- The hostfile
eddie count=4
vogon count=4
earth count=4
deep-thought count=4
- orterun -np 8 -hostfile hostfile a.out
eddie: 4 slots will be allocated
vogon: 4 slots will be allocated
earth: no slots allocated
deep-thought: no slots allocated
- orterun -bynode -np 8 -hostfile hostfile a.out
eddie: 2 slots will be allocated
vogon: 2 slots will be allocated
earth: 2 slots will be allocated
deep-thought: 2 slots will be allocated
This commit was SVN r5894.
2005-05-31 16:36:53 +00:00
|
|
|
/* This loop continues until all procs have been mapped or we run
|
2005-10-07 22:24:52 +00:00
|
|
|
out of resources. We determine that we have "run out of
|
|
|
|
resources" when all nodes have node_slots_max processes mapped to them,
|
2006-07-10 14:10:21 +00:00
|
|
|
thus there are no free slots for a process to be mapped, or we have
|
|
|
|
hit the soft limit on all nodes and are in a "no oversubscribe" state.
|
|
|
|
If we still have processes that haven't been mapped yet, then it's an
|
|
|
|
"out of resources" error.
|
|
|
|
|
|
|
|
In this scenario, we rely on the claim_slot function to handle the
|
|
|
|
oversubscribed case. The claim_slot function will leave a node on the
|
|
|
|
list until it either reachs node_slots_max OR reaches node_slots (the
|
|
|
|
soft limit) and the "no_oversubscribe" flag has been set - at which point,
|
|
|
|
the node will be removed to prevent any more processes from being mapped to
|
|
|
|
it. Since we are taking one slot from each node as we cycle through, the
|
|
|
|
list, oversubscription is automatically taken care of via this logic.
|
|
|
|
*/
|
|
|
|
|
(copied from a mail that has a lengthy description of this commit)
I spoke with Tim about this the other day -- he gave me the green
light to go ahead with this, but it turned into a bigger job than I
thought it would be. I revamped how the default RAS scheduling and
round_robin RMAPS mapping occurs. The previous algorithms were pretty
brain dead, and ignored the "slots" and "max_slots" tokens in
hostfiles. I considered this a big enough problem to fix it for the
beta (because there is currently no way to control where processes are
launched on SMPs).
There's still some more bells and whistles that I'd like to implement,
but there's no hurry, and they can go on the trunk at any time. My
patches below are for what I considered "essential", and do the
following:
- honor the "slots" and "max-slots" tokens in the hostfile (and all
their synonyms), meaning that we allocate/map until we fill slots,
and if there are still more processes to allocate/map, we keep going
until we fill max-slots (i.e., only oversubscribe a node if we have
to).
- offer two different algorithms, currently supported by two new
options to orterun. Remember that there are two parts here -- slot
allocation and process mapping. Slot allocation controls how many
processes we'll be running on a node. After that decision has been
made, process mapping effectively controls where the ranks of
MPI_COMM_WORLD (MCW) are placed. Some of the examples given below
don't make sense unless you remember that there is a difference
between the two (which makes total sense, but you have to think
about it in terms of both things):
1. "-bynode": allocates/maps one process per node in a round-robin
fashion until all slots on the node are taken. If we still have more
processes after all slots are taken, then keep going until all
max-slots are taken. Examples:
- The hostfile:
eddie slots=2 max-slots=4
vogon slots=4 max-slots=8
- orterun -bynode -np 6 -hostfile hostfile a.out
eddie: MCW ranks 0, 2
vogon: MCW ranks 1, 3, 4, 5
- orterun -bynode -np 8 -hostfile hostfile a.out
eddie: MCW ranks 0, 2, 4
vogon: MCW ranks 1, 3, 5, 6, 7
-> the algorithm oversubscribes all nodes "equally" (until each
node's max_slots is hit, of course)
- orterun -bynode -np 12 -hostfile hostfile a.out
eddie: MCW ranks 0, 2, 4, 6
vogon: MCW ranks 1, 3, 5, 7, 8, 9, 10, 11
2. "-byslot" (this is the default if you don't specify -bynode):
greedily takes all available slots on a node for a job before moving
on to the next node. If we still have processes to allocate/schedule,
then oversubscribe all nodes equally (i.e., go round robin on all
nodes until each node's max_slots is hit). Examples:
- The hostfile
eddie slots=2 max-slots=4
vogon slots=4 max-slots=8
- orterun -np 6 -hostfile hostfile a.out
eddie: MCW ranks 0, 1
vogon: MCW ranks 2, 3, 4, 5
- orterun -np 8 -hostfile hostfile a.out
eddie: MCW ranks 0, 1, 2
vogon: MCW ranks 3, 4, 5, 6, 7
-> the algorithm oversubscribes all nodes "equally" (until max_slots
is hit)
- orterun -np 12 -hostfile hostfile a.out
eddie: MCW ranks 0, 1, 2, 3
vogon: MCW ranks 4, 5, 6, 7, 8, 9, 10, 11
The above examples are fairly contrived, and it's not clear from them
that you can get different allocation answers in all cases (the
mapping differences are obvious). Consider the following allocation
example:
- The hostfile
eddie count=4
vogon count=4
earth count=4
deep-thought count=4
- orterun -np 8 -hostfile hostfile a.out
eddie: 4 slots will be allocated
vogon: 4 slots will be allocated
earth: no slots allocated
deep-thought: no slots allocated
- orterun -bynode -np 8 -hostfile hostfile a.out
eddie: 2 slots will be allocated
vogon: 2 slots will be allocated
earth: 2 slots will be allocated
deep-thought: 2 slots will be allocated
This commit was SVN r5894.
2005-05-31 16:36:53 +00:00
|
|
|
while (num_alloc < app->num_procs) {
|
2005-10-07 22:24:52 +00:00
|
|
|
|
2006-07-10 14:10:21 +00:00
|
|
|
/** see if any nodes remain unused and available. We need to do this check
|
|
|
|
* each time since we may remove nodes from the list (as they become fully
|
|
|
|
* used) as we cycle through the loop */
|
|
|
|
if(0 >= opal_list_get_size(nodes) ) {
|
|
|
|
/* No more nodes to allocate :( */
|
|
|
|
opal_show_help("help-orte-rmaps-rr.txt", "orte-rmaps-rr:alloc-error",
|
|
|
|
true, app->num_procs, app->app);
|
|
|
|
ORTE_ERROR_LOG(ORTE_ERR_OUT_OF_RESOURCE);
|
|
|
|
return ORTE_ERR_OUT_OF_RESOURCE;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Save the next node we can use before claiming slots, since
|
|
|
|
* we may need to prune the nodes list removing overused nodes.
|
|
|
|
* Wrap around to beginning if we are at the end of the list */
|
|
|
|
if (opal_list_get_end(nodes) == opal_list_get_next(cur_node_item)) {
|
|
|
|
next = opal_list_get_first(nodes);
|
2005-10-07 22:24:52 +00:00
|
|
|
}
|
|
|
|
else {
|
2006-07-10 14:10:21 +00:00
|
|
|
next = opal_list_get_next(cur_node_item);
|
2005-10-07 22:24:52 +00:00
|
|
|
}
|
2006-07-10 14:10:21 +00:00
|
|
|
|
|
|
|
/* Allocate a slot on this node */
|
|
|
|
node = (orte_ras_node_t*) cur_node_item;
|
2006-10-07 15:45:24 +00:00
|
|
|
if (ORTE_SUCCESS != (rc = orte_rmaps_base_claim_slot(map, node, jobid, vpid_start + num_alloc, app->idx,
|
2006-10-18 14:01:44 +00:00
|
|
|
nodes, max_used_nodes,
|
|
|
|
mca_rmaps_round_robin_component.oversubscribe))) {
|
2006-10-19 23:33:51 +00:00
|
|
|
/** if the code is ORTE_ERR_NODE_FULLY_USED, then we know this
|
|
|
|
* really isn't an error - we just need to break from the loop
|
|
|
|
* since the node is fully used up. For now, just don't report
|
|
|
|
* an error
|
|
|
|
*/
|
|
|
|
if (ORTE_ERR_NODE_FULLY_USED != rc) {
|
|
|
|
ORTE_ERROR_LOG(rc);
|
|
|
|
return rc;
|
|
|
|
}
|
2005-10-07 22:24:52 +00:00
|
|
|
}
|
2005-06-09 16:00:41 +00:00
|
|
|
|
2006-07-10 14:10:21 +00:00
|
|
|
++num_alloc;
|
2005-03-14 20:57:21 +00:00
|
|
|
|
(copied from a mail that has a lengthy description of this commit)
I spoke with Tim about this the other day -- he gave me the green
light to go ahead with this, but it turned into a bigger job than I
thought it would be. I revamped how the default RAS scheduling and
round_robin RMAPS mapping occurs. The previous algorithms were pretty
brain dead, and ignored the "slots" and "max_slots" tokens in
hostfiles. I considered this a big enough problem to fix it for the
beta (because there is currently no way to control where processes are
launched on SMPs).
There's still some more bells and whistles that I'd like to implement,
but there's no hurry, and they can go on the trunk at any time. My
patches below are for what I considered "essential", and do the
following:
- honor the "slots" and "max-slots" tokens in the hostfile (and all
their synonyms), meaning that we allocate/map until we fill slots,
and if there are still more processes to allocate/map, we keep going
until we fill max-slots (i.e., only oversubscribe a node if we have
to).
- offer two different algorithms, currently supported by two new
options to orterun. Remember that there are two parts here -- slot
allocation and process mapping. Slot allocation controls how many
processes we'll be running on a node. After that decision has been
made, process mapping effectively controls where the ranks of
MPI_COMM_WORLD (MCW) are placed. Some of the examples given below
don't make sense unless you remember that there is a difference
between the two (which makes total sense, but you have to think
about it in terms of both things):
1. "-bynode": allocates/maps one process per node in a round-robin
fashion until all slots on the node are taken. If we still have more
processes after all slots are taken, then keep going until all
max-slots are taken. Examples:
- The hostfile:
eddie slots=2 max-slots=4
vogon slots=4 max-slots=8
- orterun -bynode -np 6 -hostfile hostfile a.out
eddie: MCW ranks 0, 2
vogon: MCW ranks 1, 3, 4, 5
- orterun -bynode -np 8 -hostfile hostfile a.out
eddie: MCW ranks 0, 2, 4
vogon: MCW ranks 1, 3, 5, 6, 7
-> the algorithm oversubscribes all nodes "equally" (until each
node's max_slots is hit, of course)
- orterun -bynode -np 12 -hostfile hostfile a.out
eddie: MCW ranks 0, 2, 4, 6
vogon: MCW ranks 1, 3, 5, 7, 8, 9, 10, 11
2. "-byslot" (this is the default if you don't specify -bynode):
greedily takes all available slots on a node for a job before moving
on to the next node. If we still have processes to allocate/schedule,
then oversubscribe all nodes equally (i.e., go round robin on all
nodes until each node's max_slots is hit). Examples:
- The hostfile
eddie slots=2 max-slots=4
vogon slots=4 max-slots=8
- orterun -np 6 -hostfile hostfile a.out
eddie: MCW ranks 0, 1
vogon: MCW ranks 2, 3, 4, 5
- orterun -np 8 -hostfile hostfile a.out
eddie: MCW ranks 0, 1, 2
vogon: MCW ranks 3, 4, 5, 6, 7
-> the algorithm oversubscribes all nodes "equally" (until max_slots
is hit)
- orterun -np 12 -hostfile hostfile a.out
eddie: MCW ranks 0, 1, 2, 3
vogon: MCW ranks 4, 5, 6, 7, 8, 9, 10, 11
The above examples are fairly contrived, and it's not clear from them
that you can get different allocation answers in all cases (the
mapping differences are obvious). Consider the following allocation
example:
- The hostfile
eddie count=4
vogon count=4
earth count=4
deep-thought count=4
- orterun -np 8 -hostfile hostfile a.out
eddie: 4 slots will be allocated
vogon: 4 slots will be allocated
earth: no slots allocated
deep-thought: no slots allocated
- orterun -bynode -np 8 -hostfile hostfile a.out
eddie: 2 slots will be allocated
vogon: 2 slots will be allocated
earth: 2 slots will be allocated
deep-thought: 2 slots will be allocated
This commit was SVN r5894.
2005-05-31 16:36:53 +00:00
|
|
|
cur_node_item = next;
|
2005-10-07 22:24:52 +00:00
|
|
|
}
|
(copied from a mail that has a lengthy description of this commit)
I spoke with Tim about this the other day -- he gave me the green
light to go ahead with this, but it turned into a bigger job than I
thought it would be. I revamped how the default RAS scheduling and
round_robin RMAPS mapping occurs. The previous algorithms were pretty
brain dead, and ignored the "slots" and "max_slots" tokens in
hostfiles. I considered this a big enough problem to fix it for the
beta (because there is currently no way to control where processes are
launched on SMPs).
There's still some more bells and whistles that I'd like to implement,
but there's no hurry, and they can go on the trunk at any time. My
patches below are for what I considered "essential", and do the
following:
- honor the "slots" and "max-slots" tokens in the hostfile (and all
their synonyms), meaning that we allocate/map until we fill slots,
and if there are still more processes to allocate/map, we keep going
until we fill max-slots (i.e., only oversubscribe a node if we have
to).
- offer two different algorithms, currently supported by two new
options to orterun. Remember that there are two parts here -- slot
allocation and process mapping. Slot allocation controls how many
processes we'll be running on a node. After that decision has been
made, process mapping effectively controls where the ranks of
MPI_COMM_WORLD (MCW) are placed. Some of the examples given below
don't make sense unless you remember that there is a difference
between the two (which makes total sense, but you have to think
about it in terms of both things):
1. "-bynode": allocates/maps one process per node in a round-robin
fashion until all slots on the node are taken. If we still have more
processes after all slots are taken, then keep going until all
max-slots are taken. Examples:
- The hostfile:
eddie slots=2 max-slots=4
vogon slots=4 max-slots=8
- orterun -bynode -np 6 -hostfile hostfile a.out
eddie: MCW ranks 0, 2
vogon: MCW ranks 1, 3, 4, 5
- orterun -bynode -np 8 -hostfile hostfile a.out
eddie: MCW ranks 0, 2, 4
vogon: MCW ranks 1, 3, 5, 6, 7
-> the algorithm oversubscribes all nodes "equally" (until each
node's max_slots is hit, of course)
- orterun -bynode -np 12 -hostfile hostfile a.out
eddie: MCW ranks 0, 2, 4, 6
vogon: MCW ranks 1, 3, 5, 7, 8, 9, 10, 11
2. "-byslot" (this is the default if you don't specify -bynode):
greedily takes all available slots on a node for a job before moving
on to the next node. If we still have processes to allocate/schedule,
then oversubscribe all nodes equally (i.e., go round robin on all
nodes until each node's max_slots is hit). Examples:
- The hostfile
eddie slots=2 max-slots=4
vogon slots=4 max-slots=8
- orterun -np 6 -hostfile hostfile a.out
eddie: MCW ranks 0, 1
vogon: MCW ranks 2, 3, 4, 5
- orterun -np 8 -hostfile hostfile a.out
eddie: MCW ranks 0, 1, 2
vogon: MCW ranks 3, 4, 5, 6, 7
-> the algorithm oversubscribes all nodes "equally" (until max_slots
is hit)
- orterun -np 12 -hostfile hostfile a.out
eddie: MCW ranks 0, 1, 2, 3
vogon: MCW ranks 4, 5, 6, 7, 8, 9, 10, 11
The above examples are fairly contrived, and it's not clear from them
that you can get different allocation answers in all cases (the
mapping differences are obvious). Consider the following allocation
example:
- The hostfile
eddie count=4
vogon count=4
earth count=4
deep-thought count=4
- orterun -np 8 -hostfile hostfile a.out
eddie: 4 slots will be allocated
vogon: 4 slots will be allocated
earth: no slots allocated
deep-thought: no slots allocated
- orterun -bynode -np 8 -hostfile hostfile a.out
eddie: 2 slots will be allocated
vogon: 2 slots will be allocated
earth: 2 slots will be allocated
deep-thought: 2 slots will be allocated
This commit was SVN r5894.
2005-05-31 16:36:53 +00:00
|
|
|
|
2006-07-10 14:10:21 +00:00
|
|
|
return ORTE_SUCCESS;
|
(copied from a mail that has a lengthy description of this commit)
I spoke with Tim about this the other day -- he gave me the green
light to go ahead with this, but it turned into a bigger job than I
thought it would be. I revamped how the default RAS scheduling and
round_robin RMAPS mapping occurs. The previous algorithms were pretty
brain dead, and ignored the "slots" and "max_slots" tokens in
hostfiles. I considered this a big enough problem to fix it for the
beta (because there is currently no way to control where processes are
launched on SMPs).
There's still some more bells and whistles that I'd like to implement,
but there's no hurry, and they can go on the trunk at any time. My
patches below are for what I considered "essential", and do the
following:
- honor the "slots" and "max-slots" tokens in the hostfile (and all
their synonyms), meaning that we allocate/map until we fill slots,
and if there are still more processes to allocate/map, we keep going
until we fill max-slots (i.e., only oversubscribe a node if we have
to).
- offer two different algorithms, currently supported by two new
options to orterun. Remember that there are two parts here -- slot
allocation and process mapping. Slot allocation controls how many
processes we'll be running on a node. After that decision has been
made, process mapping effectively controls where the ranks of
MPI_COMM_WORLD (MCW) are placed. Some of the examples given below
don't make sense unless you remember that there is a difference
between the two (which makes total sense, but you have to think
about it in terms of both things):
1. "-bynode": allocates/maps one process per node in a round-robin
fashion until all slots on the node are taken. If we still have more
processes after all slots are taken, then keep going until all
max-slots are taken. Examples:
- The hostfile:
eddie slots=2 max-slots=4
vogon slots=4 max-slots=8
- orterun -bynode -np 6 -hostfile hostfile a.out
eddie: MCW ranks 0, 2
vogon: MCW ranks 1, 3, 4, 5
- orterun -bynode -np 8 -hostfile hostfile a.out
eddie: MCW ranks 0, 2, 4
vogon: MCW ranks 1, 3, 5, 6, 7
-> the algorithm oversubscribes all nodes "equally" (until each
node's max_slots is hit, of course)
- orterun -bynode -np 12 -hostfile hostfile a.out
eddie: MCW ranks 0, 2, 4, 6
vogon: MCW ranks 1, 3, 5, 7, 8, 9, 10, 11
2. "-byslot" (this is the default if you don't specify -bynode):
greedily takes all available slots on a node for a job before moving
on to the next node. If we still have processes to allocate/schedule,
then oversubscribe all nodes equally (i.e., go round robin on all
nodes until each node's max_slots is hit). Examples:
- The hostfile
eddie slots=2 max-slots=4
vogon slots=4 max-slots=8
- orterun -np 6 -hostfile hostfile a.out
eddie: MCW ranks 0, 1
vogon: MCW ranks 2, 3, 4, 5
- orterun -np 8 -hostfile hostfile a.out
eddie: MCW ranks 0, 1, 2
vogon: MCW ranks 3, 4, 5, 6, 7
-> the algorithm oversubscribes all nodes "equally" (until max_slots
is hit)
- orterun -np 12 -hostfile hostfile a.out
eddie: MCW ranks 0, 1, 2, 3
vogon: MCW ranks 4, 5, 6, 7, 8, 9, 10, 11
The above examples are fairly contrived, and it's not clear from them
that you can get different allocation answers in all cases (the
mapping differences are obvious). Consider the following allocation
example:
- The hostfile
eddie count=4
vogon count=4
earth count=4
deep-thought count=4
- orterun -np 8 -hostfile hostfile a.out
eddie: 4 slots will be allocated
vogon: 4 slots will be allocated
earth: no slots allocated
deep-thought: no slots allocated
- orterun -bynode -np 8 -hostfile hostfile a.out
eddie: 2 slots will be allocated
vogon: 2 slots will be allocated
earth: 2 slots will be allocated
deep-thought: 2 slots will be allocated
This commit was SVN r5894.
2005-05-31 16:36:53 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Create a default mapping for the application, scheduling one round
|
|
|
|
* robin by slot.
|
|
|
|
*/
|
|
|
|
static int map_app_by_slot(
|
2005-08-25 15:42:41 +00:00
|
|
|
orte_app_context_t* app,
|
2006-10-07 15:45:24 +00:00
|
|
|
orte_job_map_t* map,
|
(copied from a mail that has a lengthy description of this commit)
I spoke with Tim about this the other day -- he gave me the green
light to go ahead with this, but it turned into a bigger job than I
thought it would be. I revamped how the default RAS scheduling and
round_robin RMAPS mapping occurs. The previous algorithms were pretty
brain dead, and ignored the "slots" and "max_slots" tokens in
hostfiles. I considered this a big enough problem to fix it for the
beta (because there is currently no way to control where processes are
launched on SMPs).
There's still some more bells and whistles that I'd like to implement,
but there's no hurry, and they can go on the trunk at any time. My
patches below are for what I considered "essential", and do the
following:
- honor the "slots" and "max-slots" tokens in the hostfile (and all
their synonyms), meaning that we allocate/map until we fill slots,
and if there are still more processes to allocate/map, we keep going
until we fill max-slots (i.e., only oversubscribe a node if we have
to).
- offer two different algorithms, currently supported by two new
options to orterun. Remember that there are two parts here -- slot
allocation and process mapping. Slot allocation controls how many
processes we'll be running on a node. After that decision has been
made, process mapping effectively controls where the ranks of
MPI_COMM_WORLD (MCW) are placed. Some of the examples given below
don't make sense unless you remember that there is a difference
between the two (which makes total sense, but you have to think
about it in terms of both things):
1. "-bynode": allocates/maps one process per node in a round-robin
fashion until all slots on the node are taken. If we still have more
processes after all slots are taken, then keep going until all
max-slots are taken. Examples:
- The hostfile:
eddie slots=2 max-slots=4
vogon slots=4 max-slots=8
- orterun -bynode -np 6 -hostfile hostfile a.out
eddie: MCW ranks 0, 2
vogon: MCW ranks 1, 3, 4, 5
- orterun -bynode -np 8 -hostfile hostfile a.out
eddie: MCW ranks 0, 2, 4
vogon: MCW ranks 1, 3, 5, 6, 7
-> the algorithm oversubscribes all nodes "equally" (until each
node's max_slots is hit, of course)
- orterun -bynode -np 12 -hostfile hostfile a.out
eddie: MCW ranks 0, 2, 4, 6
vogon: MCW ranks 1, 3, 5, 7, 8, 9, 10, 11
2. "-byslot" (this is the default if you don't specify -bynode):
greedily takes all available slots on a node for a job before moving
on to the next node. If we still have processes to allocate/schedule,
then oversubscribe all nodes equally (i.e., go round robin on all
nodes until each node's max_slots is hit). Examples:
- The hostfile
eddie slots=2 max-slots=4
vogon slots=4 max-slots=8
- orterun -np 6 -hostfile hostfile a.out
eddie: MCW ranks 0, 1
vogon: MCW ranks 2, 3, 4, 5
- orterun -np 8 -hostfile hostfile a.out
eddie: MCW ranks 0, 1, 2
vogon: MCW ranks 3, 4, 5, 6, 7
-> the algorithm oversubscribes all nodes "equally" (until max_slots
is hit)
- orterun -np 12 -hostfile hostfile a.out
eddie: MCW ranks 0, 1, 2, 3
vogon: MCW ranks 4, 5, 6, 7, 8, 9, 10, 11
The above examples are fairly contrived, and it's not clear from them
that you can get different allocation answers in all cases (the
mapping differences are obvious). Consider the following allocation
example:
- The hostfile
eddie count=4
vogon count=4
earth count=4
deep-thought count=4
- orterun -np 8 -hostfile hostfile a.out
eddie: 4 slots will be allocated
vogon: 4 slots will be allocated
earth: no slots allocated
deep-thought: no slots allocated
- orterun -bynode -np 8 -hostfile hostfile a.out
eddie: 2 slots will be allocated
vogon: 2 slots will be allocated
earth: 2 slots will be allocated
deep-thought: 2 slots will be allocated
This commit was SVN r5894.
2005-05-31 16:36:53 +00:00
|
|
|
orte_jobid_t jobid,
|
|
|
|
orte_vpid_t vpid_start,
|
2005-10-07 22:24:52 +00:00
|
|
|
opal_list_t* nodes,
|
2007-07-14 15:14:07 +00:00
|
|
|
opal_list_t* max_used_nodes,
|
|
|
|
orte_std_cntr_t num_alloc)
|
(copied from a mail that has a lengthy description of this commit)
I spoke with Tim about this the other day -- he gave me the green
light to go ahead with this, but it turned into a bigger job than I
thought it would be. I revamped how the default RAS scheduling and
round_robin RMAPS mapping occurs. The previous algorithms were pretty
brain dead, and ignored the "slots" and "max_slots" tokens in
hostfiles. I considered this a big enough problem to fix it for the
beta (because there is currently no way to control where processes are
launched on SMPs).
There's still some more bells and whistles that I'd like to implement,
but there's no hurry, and they can go on the trunk at any time. My
patches below are for what I considered "essential", and do the
following:
- honor the "slots" and "max-slots" tokens in the hostfile (and all
their synonyms), meaning that we allocate/map until we fill slots,
and if there are still more processes to allocate/map, we keep going
until we fill max-slots (i.e., only oversubscribe a node if we have
to).
- offer two different algorithms, currently supported by two new
options to orterun. Remember that there are two parts here -- slot
allocation and process mapping. Slot allocation controls how many
processes we'll be running on a node. After that decision has been
made, process mapping effectively controls where the ranks of
MPI_COMM_WORLD (MCW) are placed. Some of the examples given below
don't make sense unless you remember that there is a difference
between the two (which makes total sense, but you have to think
about it in terms of both things):
1. "-bynode": allocates/maps one process per node in a round-robin
fashion until all slots on the node are taken. If we still have more
processes after all slots are taken, then keep going until all
max-slots are taken. Examples:
- The hostfile:
eddie slots=2 max-slots=4
vogon slots=4 max-slots=8
- orterun -bynode -np 6 -hostfile hostfile a.out
eddie: MCW ranks 0, 2
vogon: MCW ranks 1, 3, 4, 5
- orterun -bynode -np 8 -hostfile hostfile a.out
eddie: MCW ranks 0, 2, 4
vogon: MCW ranks 1, 3, 5, 6, 7
-> the algorithm oversubscribes all nodes "equally" (until each
node's max_slots is hit, of course)
- orterun -bynode -np 12 -hostfile hostfile a.out
eddie: MCW ranks 0, 2, 4, 6
vogon: MCW ranks 1, 3, 5, 7, 8, 9, 10, 11
2. "-byslot" (this is the default if you don't specify -bynode):
greedily takes all available slots on a node for a job before moving
on to the next node. If we still have processes to allocate/schedule,
then oversubscribe all nodes equally (i.e., go round robin on all
nodes until each node's max_slots is hit). Examples:
- The hostfile
eddie slots=2 max-slots=4
vogon slots=4 max-slots=8
- orterun -np 6 -hostfile hostfile a.out
eddie: MCW ranks 0, 1
vogon: MCW ranks 2, 3, 4, 5
- orterun -np 8 -hostfile hostfile a.out
eddie: MCW ranks 0, 1, 2
vogon: MCW ranks 3, 4, 5, 6, 7
-> the algorithm oversubscribes all nodes "equally" (until max_slots
is hit)
- orterun -np 12 -hostfile hostfile a.out
eddie: MCW ranks 0, 1, 2, 3
vogon: MCW ranks 4, 5, 6, 7, 8, 9, 10, 11
The above examples are fairly contrived, and it's not clear from them
that you can get different allocation answers in all cases (the
mapping differences are obvious). Consider the following allocation
example:
- The hostfile
eddie count=4
vogon count=4
earth count=4
deep-thought count=4
- orterun -np 8 -hostfile hostfile a.out
eddie: 4 slots will be allocated
vogon: 4 slots will be allocated
earth: no slots allocated
deep-thought: no slots allocated
- orterun -bynode -np 8 -hostfile hostfile a.out
eddie: 2 slots will be allocated
vogon: 2 slots will be allocated
earth: 2 slots will be allocated
deep-thought: 2 slots will be allocated
This commit was SVN r5894.
2005-05-31 16:36:53 +00:00
|
|
|
{
|
2005-10-07 22:24:52 +00:00
|
|
|
int rc = ORTE_SUCCESS;
|
2006-08-15 19:54:10 +00:00
|
|
|
orte_std_cntr_t i, num_slots_to_take;
|
2005-08-11 19:51:50 +00:00
|
|
|
orte_ras_node_t *node;
|
2006-07-10 14:10:21 +00:00
|
|
|
opal_list_item_t *next;
|
(copied from a mail that has a lengthy description of this commit)
I spoke with Tim about this the other day -- he gave me the green
light to go ahead with this, but it turned into a bigger job than I
thought it would be. I revamped how the default RAS scheduling and
round_robin RMAPS mapping occurs. The previous algorithms were pretty
brain dead, and ignored the "slots" and "max_slots" tokens in
hostfiles. I considered this a big enough problem to fix it for the
beta (because there is currently no way to control where processes are
launched on SMPs).
There's still some more bells and whistles that I'd like to implement,
but there's no hurry, and they can go on the trunk at any time. My
patches below are for what I considered "essential", and do the
following:
- honor the "slots" and "max-slots" tokens in the hostfile (and all
their synonyms), meaning that we allocate/map until we fill slots,
and if there are still more processes to allocate/map, we keep going
until we fill max-slots (i.e., only oversubscribe a node if we have
to).
- offer two different algorithms, currently supported by two new
options to orterun. Remember that there are two parts here -- slot
allocation and process mapping. Slot allocation controls how many
processes we'll be running on a node. After that decision has been
made, process mapping effectively controls where the ranks of
MPI_COMM_WORLD (MCW) are placed. Some of the examples given below
don't make sense unless you remember that there is a difference
between the two (which makes total sense, but you have to think
about it in terms of both things):
1. "-bynode": allocates/maps one process per node in a round-robin
fashion until all slots on the node are taken. If we still have more
processes after all slots are taken, then keep going until all
max-slots are taken. Examples:
- The hostfile:
eddie slots=2 max-slots=4
vogon slots=4 max-slots=8
- orterun -bynode -np 6 -hostfile hostfile a.out
eddie: MCW ranks 0, 2
vogon: MCW ranks 1, 3, 4, 5
- orterun -bynode -np 8 -hostfile hostfile a.out
eddie: MCW ranks 0, 2, 4
vogon: MCW ranks 1, 3, 5, 6, 7
-> the algorithm oversubscribes all nodes "equally" (until each
node's max_slots is hit, of course)
- orterun -bynode -np 12 -hostfile hostfile a.out
eddie: MCW ranks 0, 2, 4, 6
vogon: MCW ranks 1, 3, 5, 7, 8, 9, 10, 11
2. "-byslot" (this is the default if you don't specify -bynode):
greedily takes all available slots on a node for a job before moving
on to the next node. If we still have processes to allocate/schedule,
then oversubscribe all nodes equally (i.e., go round robin on all
nodes until each node's max_slots is hit). Examples:
- The hostfile
eddie slots=2 max-slots=4
vogon slots=4 max-slots=8
- orterun -np 6 -hostfile hostfile a.out
eddie: MCW ranks 0, 1
vogon: MCW ranks 2, 3, 4, 5
- orterun -np 8 -hostfile hostfile a.out
eddie: MCW ranks 0, 1, 2
vogon: MCW ranks 3, 4, 5, 6, 7
-> the algorithm oversubscribes all nodes "equally" (until max_slots
is hit)
- orterun -np 12 -hostfile hostfile a.out
eddie: MCW ranks 0, 1, 2, 3
vogon: MCW ranks 4, 5, 6, 7, 8, 9, 10, 11
The above examples are fairly contrived, and it's not clear from them
that you can get different allocation answers in all cases (the
mapping differences are obvious). Consider the following allocation
example:
- The hostfile
eddie count=4
vogon count=4
earth count=4
deep-thought count=4
- orterun -np 8 -hostfile hostfile a.out
eddie: 4 slots will be allocated
vogon: 4 slots will be allocated
earth: no slots allocated
deep-thought: no slots allocated
- orterun -bynode -np 8 -hostfile hostfile a.out
eddie: 2 slots will be allocated
vogon: 2 slots will be allocated
earth: 2 slots will be allocated
deep-thought: 2 slots will be allocated
This commit was SVN r5894.
2005-05-31 16:36:53 +00:00
|
|
|
|
2006-10-07 15:45:24 +00:00
|
|
|
OPAL_TRACE(2);
|
|
|
|
|
2005-10-07 22:24:52 +00:00
|
|
|
/* This loop continues until all procs have been mapped or we run
|
|
|
|
out of resources. We determine that we have "run out of
|
2006-07-10 14:10:21 +00:00
|
|
|
resources" when either all nodes have node_slots_max processes mapped to them,
|
|
|
|
(thus there are no free slots for a process to be mapped), OR all nodes
|
|
|
|
have reached their soft limit and the user directed us to "no oversubscribe".
|
|
|
|
If we still have processes that haven't been mapped yet, then it's an
|
2005-10-07 22:24:52 +00:00
|
|
|
"out of resources" error. */
|
2006-07-10 14:10:21 +00:00
|
|
|
|
2005-10-07 22:24:52 +00:00
|
|
|
while ( num_alloc < app->num_procs) {
|
2006-07-10 14:10:21 +00:00
|
|
|
|
|
|
|
/** see if any nodes remain unused and available. We need to do this check
|
|
|
|
* each time since we may remove nodes from the list (as they become fully
|
|
|
|
* used) as we cycle through the loop */
|
|
|
|
if(0 >= opal_list_get_size(nodes) ) {
|
2006-10-17 19:35:00 +00:00
|
|
|
/* Everything is at max usage! :( */
|
2006-07-10 14:10:21 +00:00
|
|
|
opal_show_help("help-orte-rmaps-rr.txt", "orte-rmaps-rr:alloc-error",
|
|
|
|
true, app->num_procs, app->app);
|
|
|
|
ORTE_ERROR_LOG(ORTE_ERR_OUT_OF_RESOURCE);
|
|
|
|
return ORTE_ERR_OUT_OF_RESOURCE;
|
|
|
|
}
|
2005-10-07 22:24:52 +00:00
|
|
|
|
2006-07-10 14:10:21 +00:00
|
|
|
/* Save the next node we can use before claiming slots, since
|
|
|
|
* we may need to prune the nodes list removing overused nodes.
|
|
|
|
* Wrap around to beginning if we are at the end of the list */
|
|
|
|
if (opal_list_get_end(nodes) == opal_list_get_next(cur_node_item)) {
|
|
|
|
next = opal_list_get_first(nodes);
|
2005-10-07 22:24:52 +00:00
|
|
|
}
|
|
|
|
else {
|
2006-07-10 14:10:21 +00:00
|
|
|
next = opal_list_get_next(cur_node_item);
|
2005-10-07 22:24:52 +00:00
|
|
|
}
|
2006-07-10 14:10:21 +00:00
|
|
|
|
|
|
|
/** declare a shorter name for convenience in the code below */
|
|
|
|
node = (orte_ras_node_t*) cur_node_item;
|
|
|
|
|
2005-10-07 22:24:52 +00:00
|
|
|
/* If we have available slots on this node, claim all of them
|
|
|
|
* If node_slots == 0, assume 1 slot for that node.
|
2006-07-10 14:10:21 +00:00
|
|
|
* JJH - is this assumption fully justified?
|
|
|
|
*
|
2006-10-20 18:24:14 +00:00
|
|
|
* If we are now oversubscribing the nodes, then we still take:
|
|
|
|
* (a) if the node has not been used yet, we take a full node_slots
|
|
|
|
* (b) if some of the slots are in-use, then we take the number of
|
|
|
|
* remaining slots before hitting the soft limit (node_slots)
|
|
|
|
* (c) if we are at or above the soft limit, we take a full node_slots
|
|
|
|
*
|
|
|
|
* Note: if node_slots is zero, then we always just take 1 slot
|
|
|
|
*
|
|
|
|
* We continue this process until either everything is done,
|
|
|
|
* or all nodes have hit their hard limit. This algorithm ensures we
|
|
|
|
* fully utilize each node before oversubscribing, and preserves the ratio
|
|
|
|
* of processes between the nodes thereafter (e.g., if one node has twice as
|
2006-07-10 14:10:21 +00:00
|
|
|
* many processes as another before oversubscribing, it will continue
|
|
|
|
* to do so after oversubscribing).
|
|
|
|
*/
|
2006-10-20 18:24:14 +00:00
|
|
|
if (0 == node->node_slots_inuse ||
|
|
|
|
node->node_slots_inuse >= node->node_slots) {
|
|
|
|
num_slots_to_take = (node->node_slots == 0) ? 1 : node->node_slots;
|
|
|
|
} else {
|
|
|
|
num_slots_to_take = node->node_slots - node->node_slots_inuse;
|
|
|
|
}
|
2006-07-10 14:10:21 +00:00
|
|
|
|
2007-01-18 17:15:19 +00:00
|
|
|
/* check if we are in npernode mode - if so, then set the num_slots_to_take
|
|
|
|
* to the num_per_node
|
|
|
|
*/
|
|
|
|
if (mca_rmaps_round_robin_component.n_per_node) {
|
|
|
|
num_slots_to_take = num_per_node;
|
|
|
|
}
|
|
|
|
|
2006-07-10 14:10:21 +00:00
|
|
|
for( i = 0; i < num_slots_to_take; ++i) {
|
2006-10-07 15:45:24 +00:00
|
|
|
if (ORTE_SUCCESS != (rc = orte_rmaps_base_claim_slot(map, node, jobid, vpid_start + num_alloc, app->idx,
|
2006-10-18 14:01:44 +00:00
|
|
|
nodes, max_used_nodes,
|
|
|
|
mca_rmaps_round_robin_component.oversubscribe))) {
|
2006-07-10 14:10:21 +00:00
|
|
|
/** if the code is ORTE_ERR_NODE_FULLY_USED, then we know this
|
|
|
|
* really isn't an error - we just need to break from the loop
|
|
|
|
* since the node is fully used up. For now, just don't report
|
|
|
|
* an error
|
|
|
|
*/
|
|
|
|
if (ORTE_ERR_NODE_FULLY_USED != rc) {
|
|
|
|
ORTE_ERROR_LOG(rc);
|
|
|
|
return rc;
|
2005-10-07 22:24:52 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2006-07-20 21:06:15 +00:00
|
|
|
/* Update the number of procs allocated */
|
2005-10-07 22:24:52 +00:00
|
|
|
++num_alloc;
|
2006-07-10 14:10:21 +00:00
|
|
|
|
|
|
|
/** if all the procs have been mapped OR we have fully used up this node, then
|
|
|
|
* break from the loop
|
|
|
|
*/
|
2006-10-19 18:57:29 +00:00
|
|
|
if(num_alloc == app->num_procs || ORTE_ERR_NODE_FULLY_USED == rc) {
|
2005-10-07 22:24:52 +00:00
|
|
|
break;
|
|
|
|
}
|
(copied from a mail that has a lengthy description of this commit)
I spoke with Tim about this the other day -- he gave me the green
light to go ahead with this, but it turned into a bigger job than I
thought it would be. I revamped how the default RAS scheduling and
round_robin RMAPS mapping occurs. The previous algorithms were pretty
brain dead, and ignored the "slots" and "max_slots" tokens in
hostfiles. I considered this a big enough problem to fix it for the
beta (because there is currently no way to control where processes are
launched on SMPs).
There's still some more bells and whistles that I'd like to implement,
but there's no hurry, and they can go on the trunk at any time. My
patches below are for what I considered "essential", and do the
following:
- honor the "slots" and "max-slots" tokens in the hostfile (and all
their synonyms), meaning that we allocate/map until we fill slots,
and if there are still more processes to allocate/map, we keep going
until we fill max-slots (i.e., only oversubscribe a node if we have
to).
- offer two different algorithms, currently supported by two new
options to orterun. Remember that there are two parts here -- slot
allocation and process mapping. Slot allocation controls how many
processes we'll be running on a node. After that decision has been
made, process mapping effectively controls where the ranks of
MPI_COMM_WORLD (MCW) are placed. Some of the examples given below
don't make sense unless you remember that there is a difference
between the two (which makes total sense, but you have to think
about it in terms of both things):
1. "-bynode": allocates/maps one process per node in a round-robin
fashion until all slots on the node are taken. If we still have more
processes after all slots are taken, then keep going until all
max-slots are taken. Examples:
- The hostfile:
eddie slots=2 max-slots=4
vogon slots=4 max-slots=8
- orterun -bynode -np 6 -hostfile hostfile a.out
eddie: MCW ranks 0, 2
vogon: MCW ranks 1, 3, 4, 5
- orterun -bynode -np 8 -hostfile hostfile a.out
eddie: MCW ranks 0, 2, 4
vogon: MCW ranks 1, 3, 5, 6, 7
-> the algorithm oversubscribes all nodes "equally" (until each
node's max_slots is hit, of course)
- orterun -bynode -np 12 -hostfile hostfile a.out
eddie: MCW ranks 0, 2, 4, 6
vogon: MCW ranks 1, 3, 5, 7, 8, 9, 10, 11
2. "-byslot" (this is the default if you don't specify -bynode):
greedily takes all available slots on a node for a job before moving
on to the next node. If we still have processes to allocate/schedule,
then oversubscribe all nodes equally (i.e., go round robin on all
nodes until each node's max_slots is hit). Examples:
- The hostfile
eddie slots=2 max-slots=4
vogon slots=4 max-slots=8
- orterun -np 6 -hostfile hostfile a.out
eddie: MCW ranks 0, 1
vogon: MCW ranks 2, 3, 4, 5
- orterun -np 8 -hostfile hostfile a.out
eddie: MCW ranks 0, 1, 2
vogon: MCW ranks 3, 4, 5, 6, 7
-> the algorithm oversubscribes all nodes "equally" (until max_slots
is hit)
- orterun -np 12 -hostfile hostfile a.out
eddie: MCW ranks 0, 1, 2, 3
vogon: MCW ranks 4, 5, 6, 7, 8, 9, 10, 11
The above examples are fairly contrived, and it's not clear from them
that you can get different allocation answers in all cases (the
mapping differences are obvious). Consider the following allocation
example:
- The hostfile
eddie count=4
vogon count=4
earth count=4
deep-thought count=4
- orterun -np 8 -hostfile hostfile a.out
eddie: 4 slots will be allocated
vogon: 4 slots will be allocated
earth: no slots allocated
deep-thought: no slots allocated
- orterun -bynode -np 8 -hostfile hostfile a.out
eddie: 2 slots will be allocated
vogon: 2 slots will be allocated
earth: 2 slots will be allocated
deep-thought: 2 slots will be allocated
This commit was SVN r5894.
2005-05-31 16:36:53 +00:00
|
|
|
}
|
|
|
|
|
2006-10-20 18:05:16 +00:00
|
|
|
/* we move on to the next node in all cases EXCEPT if we came
|
|
|
|
* out of the loop without having taken a full bite AND the
|
|
|
|
* node is NOT max'd out
|
|
|
|
*
|
|
|
|
*/
|
|
|
|
if (i < (num_slots_to_take-1) && ORTE_ERR_NODE_FULLY_USED != rc) {
|
|
|
|
continue;
|
2006-10-19 18:57:29 +00:00
|
|
|
}
|
2006-10-20 18:05:16 +00:00
|
|
|
cur_node_item = next;
|
2005-08-25 15:42:41 +00:00
|
|
|
}
|
(copied from a mail that has a lengthy description of this commit)
I spoke with Tim about this the other day -- he gave me the green
light to go ahead with this, but it turned into a bigger job than I
thought it would be. I revamped how the default RAS scheduling and
round_robin RMAPS mapping occurs. The previous algorithms were pretty
brain dead, and ignored the "slots" and "max_slots" tokens in
hostfiles. I considered this a big enough problem to fix it for the
beta (because there is currently no way to control where processes are
launched on SMPs).
There's still some more bells and whistles that I'd like to implement,
but there's no hurry, and they can go on the trunk at any time. My
patches below are for what I considered "essential", and do the
following:
- honor the "slots" and "max-slots" tokens in the hostfile (and all
their synonyms), meaning that we allocate/map until we fill slots,
and if there are still more processes to allocate/map, we keep going
until we fill max-slots (i.e., only oversubscribe a node if we have
to).
- offer two different algorithms, currently supported by two new
options to orterun. Remember that there are two parts here -- slot
allocation and process mapping. Slot allocation controls how many
processes we'll be running on a node. After that decision has been
made, process mapping effectively controls where the ranks of
MPI_COMM_WORLD (MCW) are placed. Some of the examples given below
don't make sense unless you remember that there is a difference
between the two (which makes total sense, but you have to think
about it in terms of both things):
1. "-bynode": allocates/maps one process per node in a round-robin
fashion until all slots on the node are taken. If we still have more
processes after all slots are taken, then keep going until all
max-slots are taken. Examples:
- The hostfile:
eddie slots=2 max-slots=4
vogon slots=4 max-slots=8
- orterun -bynode -np 6 -hostfile hostfile a.out
eddie: MCW ranks 0, 2
vogon: MCW ranks 1, 3, 4, 5
- orterun -bynode -np 8 -hostfile hostfile a.out
eddie: MCW ranks 0, 2, 4
vogon: MCW ranks 1, 3, 5, 6, 7
-> the algorithm oversubscribes all nodes "equally" (until each
node's max_slots is hit, of course)
- orterun -bynode -np 12 -hostfile hostfile a.out
eddie: MCW ranks 0, 2, 4, 6
vogon: MCW ranks 1, 3, 5, 7, 8, 9, 10, 11
2. "-byslot" (this is the default if you don't specify -bynode):
greedily takes all available slots on a node for a job before moving
on to the next node. If we still have processes to allocate/schedule,
then oversubscribe all nodes equally (i.e., go round robin on all
nodes until each node's max_slots is hit). Examples:
- The hostfile
eddie slots=2 max-slots=4
vogon slots=4 max-slots=8
- orterun -np 6 -hostfile hostfile a.out
eddie: MCW ranks 0, 1
vogon: MCW ranks 2, 3, 4, 5
- orterun -np 8 -hostfile hostfile a.out
eddie: MCW ranks 0, 1, 2
vogon: MCW ranks 3, 4, 5, 6, 7
-> the algorithm oversubscribes all nodes "equally" (until max_slots
is hit)
- orterun -np 12 -hostfile hostfile a.out
eddie: MCW ranks 0, 1, 2, 3
vogon: MCW ranks 4, 5, 6, 7, 8, 9, 10, 11
The above examples are fairly contrived, and it's not clear from them
that you can get different allocation answers in all cases (the
mapping differences are obvious). Consider the following allocation
example:
- The hostfile
eddie count=4
vogon count=4
earth count=4
deep-thought count=4
- orterun -np 8 -hostfile hostfile a.out
eddie: 4 slots will be allocated
vogon: 4 slots will be allocated
earth: no slots allocated
deep-thought: no slots allocated
- orterun -bynode -np 8 -hostfile hostfile a.out
eddie: 2 slots will be allocated
vogon: 2 slots will be allocated
earth: 2 slots will be allocated
deep-thought: 2 slots will be allocated
This commit was SVN r5894.
2005-05-31 16:36:53 +00:00
|
|
|
|
2006-07-10 14:10:21 +00:00
|
|
|
return ORTE_SUCCESS;
|
2005-03-14 20:57:21 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
2006-10-18 14:01:44 +00:00
|
|
|
/*
|
|
|
|
* Process the attributes and push them into our local "global"
|
|
|
|
*/
|
|
|
|
static int orte_rmaps_rr_process_attrs(opal_list_t *attributes)
|
|
|
|
{
|
|
|
|
int rc;
|
|
|
|
char *policy;
|
|
|
|
orte_attribute_t *attr;
|
2006-12-12 00:54:05 +00:00
|
|
|
orte_std_cntr_t *scptr;
|
2007-01-18 17:15:19 +00:00
|
|
|
bool policy_override;
|
2006-10-18 14:01:44 +00:00
|
|
|
|
2007-01-18 17:15:19 +00:00
|
|
|
mca_rmaps_round_robin_component.bynode = false; /* set default mapping policy to byslot*/
|
|
|
|
policy_override = false;
|
|
|
|
|
2006-10-18 14:01:44 +00:00
|
|
|
mca_rmaps_round_robin_component.per_node = false;
|
|
|
|
if (NULL != (attr = orte_rmgr.find_attribute(attributes, ORTE_RMAPS_PERNODE))) {
|
|
|
|
/* was provided - set boolean accordingly */
|
|
|
|
mca_rmaps_round_robin_component.per_node = true;
|
2006-12-11 18:07:07 +00:00
|
|
|
/* indicate that we are going to map this job bynode */
|
|
|
|
mca_rmaps_round_robin_component.bynode = true;
|
2007-01-18 17:15:19 +00:00
|
|
|
/* indicate that this is to *be* the policy no matter what */
|
|
|
|
policy_override = true;
|
2006-10-18 14:01:44 +00:00
|
|
|
}
|
|
|
|
|
2006-12-12 00:54:05 +00:00
|
|
|
mca_rmaps_round_robin_component.n_per_node = false;
|
|
|
|
if (NULL != (attr = orte_rmgr.find_attribute(attributes, ORTE_RMAPS_N_PERNODE))) {
|
|
|
|
/* was provided - set boolean accordingly */
|
|
|
|
mca_rmaps_round_robin_component.n_per_node = true;
|
|
|
|
/* get the number of procs per node to launch */
|
|
|
|
if (ORTE_SUCCESS != (rc = orte_dss.get((void**)&scptr, attr->value, ORTE_STD_CNTR))) {
|
|
|
|
ORTE_ERROR_LOG(rc);
|
|
|
|
return rc;
|
|
|
|
}
|
|
|
|
num_per_node = *scptr;
|
2007-01-18 17:15:19 +00:00
|
|
|
/* default to byslot mapping */
|
|
|
|
mca_rmaps_round_robin_component.bynode = false;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* define the mapping policy. This *must* come after we process the pernode
|
|
|
|
* options since those set a default mapping policy - we want to be able
|
|
|
|
* to override that setting if requested
|
|
|
|
*
|
|
|
|
* NOTE: we don't do this step if the policy_override has been set!
|
|
|
|
*/
|
|
|
|
if (!policy_override &&
|
|
|
|
NULL != (attr = orte_rmgr.find_attribute(attributes, ORTE_RMAPS_MAP_POLICY))) {
|
|
|
|
/* they specified a mapping policy - extract its name */
|
|
|
|
if (ORTE_SUCCESS != (rc = orte_dss.get((void**)&policy, attr->value, ORTE_STRING))) {
|
|
|
|
ORTE_ERROR_LOG(rc);
|
|
|
|
return rc;
|
|
|
|
}
|
|
|
|
if (0 == strcmp(policy, "bynode")) {
|
|
|
|
mca_rmaps_round_robin_component.bynode = true;
|
|
|
|
} else {
|
|
|
|
mca_rmaps_round_robin_component.bynode = false;
|
|
|
|
}
|
2006-12-12 00:54:05 +00:00
|
|
|
}
|
|
|
|
|
2006-10-18 14:01:44 +00:00
|
|
|
mca_rmaps_round_robin_component.no_use_local = false;
|
|
|
|
if (NULL != (attr = orte_rmgr.find_attribute(attributes, ORTE_RMAPS_NO_USE_LOCAL))) {
|
|
|
|
/* was provided - set boolean accordingly */
|
|
|
|
mca_rmaps_round_robin_component.no_use_local = true;
|
|
|
|
}
|
|
|
|
|
|
|
|
mca_rmaps_round_robin_component.oversubscribe = true;
|
|
|
|
if (NULL != (attr = orte_rmgr.find_attribute(attributes, ORTE_RMAPS_NO_OVERSUB))) {
|
|
|
|
/* was provided - set boolean accordingly */
|
|
|
|
mca_rmaps_round_robin_component.oversubscribe = false;
|
|
|
|
}
|
|
|
|
|
2007-01-02 16:14:44 +00:00
|
|
|
mca_rmaps_round_robin_component.no_allocate_range = false;
|
|
|
|
if (NULL != (attr = orte_rmgr.find_attribute(attributes, ORTE_RMAPS_NO_ALLOC_RANGE))) {
|
|
|
|
/* was provided - set boolean accordingly */
|
|
|
|
mca_rmaps_round_robin_component.no_allocate_range = true;
|
|
|
|
}
|
|
|
|
|
2006-10-18 14:01:44 +00:00
|
|
|
return ORTE_SUCCESS;
|
|
|
|
}
|
2005-03-14 20:57:21 +00:00
|
|
|
/*
|
2006-07-10 14:10:21 +00:00
|
|
|
* Create a round-robin mapping for the job.
|
2005-03-14 20:57:21 +00:00
|
|
|
*/
|
|
|
|
|
2006-10-18 14:01:44 +00:00
|
|
|
static int orte_rmaps_rr_map(orte_jobid_t jobid, opal_list_t *attributes)
|
2005-03-14 20:57:21 +00:00
|
|
|
{
|
2006-10-07 15:45:24 +00:00
|
|
|
orte_app_context_t *app;
|
|
|
|
orte_job_map_t* map;
|
|
|
|
orte_std_cntr_t i;
|
2007-07-14 15:14:07 +00:00
|
|
|
opal_list_t master_node_list, mapped_node_list, max_used_nodes, *working_node_list ,procs;
|
2006-07-10 14:10:21 +00:00
|
|
|
opal_list_item_t *item, *item2;
|
|
|
|
orte_ras_node_t *node, *node2;
|
2006-10-19 18:57:29 +00:00
|
|
|
char *save_bookmark;
|
2006-12-12 16:07:23 +00:00
|
|
|
orte_vpid_t vpid_start;
|
2006-12-11 18:07:07 +00:00
|
|
|
orte_std_cntr_t num_procs = 0, total_num_slots, mapped_num_slots, num_nodes, num_slots;
|
2006-07-10 14:10:21 +00:00
|
|
|
int rc;
|
2006-10-07 19:50:12 +00:00
|
|
|
bool modify_app_context = false;
|
2006-10-18 20:02:16 +00:00
|
|
|
char *sptr;
|
|
|
|
orte_attribute_t *attr;
|
2007-01-18 17:15:19 +00:00
|
|
|
orte_std_cntr_t slots_per_node;
|
2007-07-14 15:14:07 +00:00
|
|
|
orte_std_cntr_t num_alloc = 0;
|
2005-03-14 20:57:21 +00:00
|
|
|
|
2006-10-07 15:45:24 +00:00
|
|
|
OPAL_TRACE(1);
|
|
|
|
|
2006-10-18 14:01:44 +00:00
|
|
|
/* setup the local environment from the attributes */
|
|
|
|
if (ORTE_SUCCESS != (rc = orte_rmaps_rr_process_attrs(attributes))) {
|
|
|
|
ORTE_ERROR_LOG(rc);
|
|
|
|
return rc;
|
|
|
|
}
|
|
|
|
|
2006-10-07 15:45:24 +00:00
|
|
|
/* create the map object */
|
|
|
|
map = OBJ_NEW(orte_job_map_t);
|
|
|
|
if (NULL == map) {
|
|
|
|
ORTE_ERROR_LOG(ORTE_ERR_OUT_OF_RESOURCE);
|
|
|
|
return ORTE_ERR_OUT_OF_RESOURCE;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* set the jobid */
|
|
|
|
map->job = jobid;
|
|
|
|
|
2005-03-14 20:57:21 +00:00
|
|
|
/* query for the application context and allocated nodes */
|
2006-10-07 15:45:24 +00:00
|
|
|
if(ORTE_SUCCESS != (rc = orte_rmgr.get_app_context(jobid, &(map->apps), &(map->num_apps)))) {
|
2006-07-10 14:10:21 +00:00
|
|
|
ORTE_ERROR_LOG(rc);
|
2005-03-14 20:57:21 +00:00
|
|
|
return rc;
|
|
|
|
}
|
|
|
|
|
2006-07-10 14:10:21 +00:00
|
|
|
/* query for all nodes allocated to this job - this will become our master list of
|
|
|
|
* nodes. From this, we will construct a working list of nodes based on any specified
|
|
|
|
* mappings from the user
|
|
|
|
*/
|
|
|
|
OBJ_CONSTRUCT(&master_node_list, opal_list_t);
|
2007-07-14 15:14:07 +00:00
|
|
|
OBJ_CONSTRUCT(&procs, opal_list_t);
|
2006-10-18 14:01:44 +00:00
|
|
|
if(ORTE_SUCCESS != (rc = orte_rmaps_base_get_target_nodes(&master_node_list, jobid,
|
|
|
|
&total_num_slots,
|
|
|
|
mca_rmaps_round_robin_component.no_use_local))) {
|
2006-07-10 14:10:21 +00:00
|
|
|
ORTE_ERROR_LOG(rc);
|
|
|
|
OBJ_DESTRUCT(&master_node_list);
|
2005-10-07 22:24:52 +00:00
|
|
|
return rc;
|
|
|
|
}
|
|
|
|
|
2006-10-18 20:02:16 +00:00
|
|
|
/* if a bookmark exists from some prior mapping, set us to start there */
|
|
|
|
if (NULL != (attr = orte_rmgr.find_attribute(attributes, ORTE_RMAPS_BOOKMARK))) {
|
|
|
|
cur_node_item = NULL;
|
|
|
|
if (ORTE_SUCCESS != (rc = orte_dss.get((void**)&sptr, attr->value, ORTE_STRING))) {
|
|
|
|
ORTE_ERROR_LOG(rc);
|
|
|
|
return rc;
|
|
|
|
}
|
|
|
|
/* find this node on the master list */
|
|
|
|
for (item = opal_list_get_first(&master_node_list);
|
|
|
|
item != opal_list_get_end(&master_node_list);
|
|
|
|
item = opal_list_get_next(item)) {
|
|
|
|
node = (orte_ras_node_t*)item;
|
|
|
|
|
2006-10-18 21:47:01 +00:00
|
|
|
if (0 == strcmp(sptr, node->node_name)) {
|
2006-10-18 20:02:16 +00:00
|
|
|
cur_node_item = item;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
/* see if we found it - if not, just start at the beginning */
|
|
|
|
if (NULL == cur_node_item) {
|
2006-10-19 18:57:29 +00:00
|
|
|
cur_node_item = opal_list_get_first(&master_node_list);
|
2006-10-17 19:35:00 +00:00
|
|
|
}
|
2006-10-18 20:02:16 +00:00
|
|
|
} else {
|
|
|
|
/* if no bookmark, then just start at the beginning of the list */
|
|
|
|
cur_node_item = opal_list_get_first(&master_node_list);
|
2006-10-17 19:35:00 +00:00
|
|
|
}
|
2006-07-10 14:10:21 +00:00
|
|
|
|
2006-10-19 18:57:29 +00:00
|
|
|
/* save the node name for the bookmark just in case we don't do anything
|
|
|
|
* useful down below
|
|
|
|
*/
|
|
|
|
save_bookmark = strdup(((orte_ras_node_t*)cur_node_item)->node_name);
|
|
|
|
|
2006-07-10 14:10:21 +00:00
|
|
|
/** construct the list to hold any nodes that get fully used during this
|
|
|
|
* mapping. We need to keep a record of these so we can update their
|
|
|
|
* information on the registry when we are done, but we want to remove
|
|
|
|
* them from our master_node_list as we go so we don't keep checking to
|
|
|
|
* see if we can still map something onto them.
|
|
|
|
*/
|
|
|
|
OBJ_CONSTRUCT(&fully_used_nodes, opal_list_t);
|
|
|
|
|
|
|
|
/** construct an intermediate list that will hold the nodes that are fully
|
|
|
|
* used during any one pass through the mapper (i.e., for each app_context).
|
|
|
|
* we will join the results together to form the fully_used_nodes list. This
|
|
|
|
* allows us to more efficiently handle the cases where users specify
|
|
|
|
* the proc-to-node mapping themselves.
|
|
|
|
*/
|
|
|
|
OBJ_CONSTRUCT(&max_used_nodes, opal_list_t);
|
|
|
|
|
|
|
|
/** construct a list to hold any nodes involved in a user-specified mapping */
|
|
|
|
OBJ_CONSTRUCT(&mapped_node_list, opal_list_t);
|
2007-07-14 15:14:07 +00:00
|
|
|
|
|
|
|
if(ORTE_SUCCESS != (rc = orte_rmaps_base_get_target_procs(&procs))) {
|
|
|
|
ORTE_ERROR_LOG(rc);
|
|
|
|
goto cleanup;
|
|
|
|
}
|
2006-10-07 15:45:24 +00:00
|
|
|
for(i=0; i < map->num_apps; i++) {
|
|
|
|
app = map->apps[i];
|
2006-07-10 14:10:21 +00:00
|
|
|
|
2006-07-11 02:59:23 +00:00
|
|
|
/** if the number of processes wasn't specified, then we know there can be only
|
|
|
|
* one app_context allowed in the launch, and that we are to launch it across
|
|
|
|
* all available slots. We'll double-check the single app_context rule first
|
|
|
|
*/
|
2006-10-07 15:45:24 +00:00
|
|
|
if (0 == app->num_procs && 1 < map->num_apps) {
|
2006-07-11 02:59:23 +00:00
|
|
|
opal_show_help("help-orte-rmaps-rr.txt", "orte-rmaps-rr:multi-apps-and-zero-np",
|
2006-10-07 15:45:24 +00:00
|
|
|
true, map->num_apps, NULL);
|
2006-07-11 02:59:23 +00:00
|
|
|
ORTE_ERROR_LOG(ORTE_ERR_INVALID_NUM_PROCS);
|
|
|
|
return ORTE_ERR_INVALID_NUM_PROCS;
|
|
|
|
}
|
|
|
|
|
2005-10-07 22:24:52 +00:00
|
|
|
if ( 0 < app->num_map ) {
|
2006-07-10 14:10:21 +00:00
|
|
|
/** If the user has specified a mapping for this app_context, then we
|
|
|
|
* create a working node list that contains only those nodes.
|
|
|
|
*/
|
2006-10-18 14:01:44 +00:00
|
|
|
if (ORTE_SUCCESS != (rc = orte_rmaps_base_get_mapped_targets(&mapped_node_list, app,
|
|
|
|
&master_node_list, &mapped_num_slots))) {
|
2006-07-10 14:10:21 +00:00
|
|
|
ORTE_ERROR_LOG(rc);
|
2005-10-07 22:24:52 +00:00
|
|
|
goto cleanup;
|
|
|
|
}
|
2006-07-10 14:10:21 +00:00
|
|
|
working_node_list = &mapped_node_list;
|
|
|
|
/* Set cur_node_item to point to the first node in the specified list to be used */
|
|
|
|
cur_node_item = opal_list_get_first(working_node_list);
|
2006-07-11 02:59:23 +00:00
|
|
|
|
2006-12-11 18:07:07 +00:00
|
|
|
num_nodes = (orte_std_cntr_t)opal_list_get_size(&mapped_node_list);
|
|
|
|
num_slots = (orte_std_cntr_t)mapped_num_slots;
|
2006-07-10 14:10:21 +00:00
|
|
|
}
|
|
|
|
else {
|
|
|
|
/** no mapping was specified, so we are going to just use everything that was
|
|
|
|
* allocated to us. We don't need to update cur_node_item in this case since it
|
|
|
|
* is always pointing to something in the master_node_list - we'll just pick up
|
|
|
|
* from wherever we last stopped.
|
|
|
|
*/
|
|
|
|
working_node_list = &master_node_list;
|
2006-07-11 02:59:23 +00:00
|
|
|
|
2006-12-11 18:07:07 +00:00
|
|
|
num_nodes = (orte_std_cntr_t)opal_list_get_size(&master_node_list);
|
|
|
|
num_slots = total_num_slots;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (mca_rmaps_round_robin_component.per_node) {
|
|
|
|
/* there are three use-cases that we need to deal with:
|
|
|
|
* (a) if -np was not provided, then we just use the number of nodes
|
|
|
|
* (b) if -np was provided AND #procs > #nodes, then error out
|
|
|
|
* (c) if -np was provided AND #procs <= #nodes, then launch
|
|
|
|
* the specified #procs one/node. In this case, we just
|
|
|
|
* leave app->num_procs alone
|
|
|
|
*/
|
2006-07-11 02:59:23 +00:00
|
|
|
if (0 == app->num_procs) {
|
2006-12-11 18:07:07 +00:00
|
|
|
app->num_procs = num_nodes;
|
2006-07-11 02:59:23 +00:00
|
|
|
modify_app_context = true;
|
2006-12-11 18:07:07 +00:00
|
|
|
} else if (app->num_procs > num_nodes) {
|
|
|
|
opal_show_help("help-orte-rmaps-rr.txt", "orte-rmaps-rr:per-node-and-too-many-procs",
|
|
|
|
true, app->num_procs, num_nodes, NULL);
|
|
|
|
return ORTE_ERR_SILENT;
|
|
|
|
}
|
2006-12-12 00:54:05 +00:00
|
|
|
} else if (mca_rmaps_round_robin_component.n_per_node) {
|
2007-01-18 17:15:19 +00:00
|
|
|
/* first, let's check to see if there are enough slots/node to
|
|
|
|
* meet the request - error out if not
|
|
|
|
*/
|
|
|
|
slots_per_node = num_slots / num_nodes;
|
|
|
|
if (num_per_node > slots_per_node) {
|
|
|
|
opal_show_help("help-orte-rmaps-rr.txt", "orte-rmaps-rr:n-per-node-and-not-enough-slots",
|
|
|
|
true, num_per_node, slots_per_node, NULL);
|
|
|
|
return ORTE_ERR_SILENT;
|
|
|
|
}
|
|
|
|
/* there are three use-cases that we need to deal with:
|
|
|
|
* (a) if -np was not provided, then we just use the n/node * #nodes
|
|
|
|
* (b) if -np was provided AND #procs > (n/node * #nodes), then error out
|
|
|
|
* (c) if -np was provided AND #procs <= (n/node * #nodes), then launch
|
|
|
|
* the specified #procs n/node. In this case, we just
|
|
|
|
* leave app->num_procs alone
|
|
|
|
*/
|
|
|
|
if (0 == app->num_procs) {
|
|
|
|
/* set the num_procs to equal the specified num/node * the number of nodes */
|
|
|
|
app->num_procs = num_per_node * num_nodes;
|
|
|
|
modify_app_context = true;
|
|
|
|
} else if (app->num_procs > (num_per_node * num_nodes)) {
|
|
|
|
opal_show_help("help-orte-rmaps-rr.txt", "orte-rmaps-rr:n-per-node-and-too-many-procs",
|
|
|
|
true, app->num_procs, num_per_node, num_nodes, num_slots, NULL);
|
|
|
|
return ORTE_ERR_SILENT;
|
|
|
|
}
|
2006-12-11 18:07:07 +00:00
|
|
|
} else if (0 == app->num_procs) {
|
|
|
|
/** set the num_procs to equal the number of slots on these mapped nodes - if
|
|
|
|
user has specified "-bynode", then set it to the number of nodes
|
|
|
|
*/
|
|
|
|
if (mca_rmaps_round_robin_component.bynode) {
|
|
|
|
app->num_procs = num_nodes;
|
2006-11-13 19:13:21 +00:00
|
|
|
} else {
|
2006-12-11 18:07:07 +00:00
|
|
|
app->num_procs = num_slots;
|
2006-07-11 02:59:23 +00:00
|
|
|
}
|
2006-12-11 18:07:07 +00:00
|
|
|
modify_app_context = true;
|
2006-07-11 02:59:23 +00:00
|
|
|
}
|
|
|
|
|
2007-01-02 16:14:44 +00:00
|
|
|
/* allocate a vpid range for this app within the job, unless told not to do so */
|
|
|
|
if (mca_rmaps_round_robin_component.no_allocate_range) {
|
|
|
|
vpid_start = 0;
|
|
|
|
} else {
|
|
|
|
if(ORTE_SUCCESS != (rc = orte_ns.reserve_range(jobid, app->num_procs, &vpid_start))) {
|
|
|
|
ORTE_ERROR_LOG(rc);
|
|
|
|
OBJ_DESTRUCT(&master_node_list);
|
|
|
|
return rc;
|
|
|
|
}
|
2006-07-11 02:59:23 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/** save the initial starting vpid for later */
|
|
|
|
if (0 == i) {
|
2006-12-12 16:07:23 +00:00
|
|
|
map->vpid_start = vpid_start;
|
2005-10-07 22:24:52 +00:00
|
|
|
}
|
|
|
|
|
2006-07-11 02:59:23 +00:00
|
|
|
/** track the total number of processes we mapped */
|
|
|
|
num_procs += app->num_procs;
|
|
|
|
|
2007-07-14 15:14:07 +00:00
|
|
|
if(!opal_list_is_empty(&procs)){
|
|
|
|
if (ORTE_SUCCESS != (rc = map_app_by_allocated_ranks(app, map, jobid, vpid_start, working_node_list, &max_used_nodes, &procs, &num_alloc))) {
|
|
|
|
ORTE_ERROR_LOG(rc);
|
|
|
|
goto cleanup;
|
|
|
|
}
|
|
|
|
}
|
2005-10-07 22:24:52 +00:00
|
|
|
/* Make assignments */
|
2006-12-11 18:07:07 +00:00
|
|
|
if (mca_rmaps_round_robin_component.bynode) {
|
2006-12-15 02:34:14 +00:00
|
|
|
map->mapping_mode = strdup("bynode");
|
2007-07-14 15:14:07 +00:00
|
|
|
rc = map_app_by_node(app, map, jobid, vpid_start, working_node_list, &max_used_nodes, num_alloc);
|
(copied from a mail that has a lengthy description of this commit)
I spoke with Tim about this the other day -- he gave me the green
light to go ahead with this, but it turned into a bigger job than I
thought it would be. I revamped how the default RAS scheduling and
round_robin RMAPS mapping occurs. The previous algorithms were pretty
brain dead, and ignored the "slots" and "max_slots" tokens in
hostfiles. I considered this a big enough problem to fix it for the
beta (because there is currently no way to control where processes are
launched on SMPs).
There's still some more bells and whistles that I'd like to implement,
but there's no hurry, and they can go on the trunk at any time. My
patches below are for what I considered "essential", and do the
following:
- honor the "slots" and "max-slots" tokens in the hostfile (and all
their synonyms), meaning that we allocate/map until we fill slots,
and if there are still more processes to allocate/map, we keep going
until we fill max-slots (i.e., only oversubscribe a node if we have
to).
- offer two different algorithms, currently supported by two new
options to orterun. Remember that there are two parts here -- slot
allocation and process mapping. Slot allocation controls how many
processes we'll be running on a node. After that decision has been
made, process mapping effectively controls where the ranks of
MPI_COMM_WORLD (MCW) are placed. Some of the examples given below
don't make sense unless you remember that there is a difference
between the two (which makes total sense, but you have to think
about it in terms of both things):
1. "-bynode": allocates/maps one process per node in a round-robin
fashion until all slots on the node are taken. If we still have more
processes after all slots are taken, then keep going until all
max-slots are taken. Examples:
- The hostfile:
eddie slots=2 max-slots=4
vogon slots=4 max-slots=8
- orterun -bynode -np 6 -hostfile hostfile a.out
eddie: MCW ranks 0, 2
vogon: MCW ranks 1, 3, 4, 5
- orterun -bynode -np 8 -hostfile hostfile a.out
eddie: MCW ranks 0, 2, 4
vogon: MCW ranks 1, 3, 5, 6, 7
-> the algorithm oversubscribes all nodes "equally" (until each
node's max_slots is hit, of course)
- orterun -bynode -np 12 -hostfile hostfile a.out
eddie: MCW ranks 0, 2, 4, 6
vogon: MCW ranks 1, 3, 5, 7, 8, 9, 10, 11
2. "-byslot" (this is the default if you don't specify -bynode):
greedily takes all available slots on a node for a job before moving
on to the next node. If we still have processes to allocate/schedule,
then oversubscribe all nodes equally (i.e., go round robin on all
nodes until each node's max_slots is hit). Examples:
- The hostfile
eddie slots=2 max-slots=4
vogon slots=4 max-slots=8
- orterun -np 6 -hostfile hostfile a.out
eddie: MCW ranks 0, 1
vogon: MCW ranks 2, 3, 4, 5
- orterun -np 8 -hostfile hostfile a.out
eddie: MCW ranks 0, 1, 2
vogon: MCW ranks 3, 4, 5, 6, 7
-> the algorithm oversubscribes all nodes "equally" (until max_slots
is hit)
- orterun -np 12 -hostfile hostfile a.out
eddie: MCW ranks 0, 1, 2, 3
vogon: MCW ranks 4, 5, 6, 7, 8, 9, 10, 11
The above examples are fairly contrived, and it's not clear from them
that you can get different allocation answers in all cases (the
mapping differences are obvious). Consider the following allocation
example:
- The hostfile
eddie count=4
vogon count=4
earth count=4
deep-thought count=4
- orterun -np 8 -hostfile hostfile a.out
eddie: 4 slots will be allocated
vogon: 4 slots will be allocated
earth: no slots allocated
deep-thought: no slots allocated
- orterun -bynode -np 8 -hostfile hostfile a.out
eddie: 2 slots will be allocated
vogon: 2 slots will be allocated
earth: 2 slots will be allocated
deep-thought: 2 slots will be allocated
This commit was SVN r5894.
2005-05-31 16:36:53 +00:00
|
|
|
} else {
|
2006-12-15 02:34:14 +00:00
|
|
|
map->mapping_mode = strdup("byslot");
|
2007-07-14 15:14:07 +00:00
|
|
|
rc = map_app_by_slot(app, map, jobid, vpid_start, working_node_list, &max_used_nodes, num_alloc);
|
(copied from a mail that has a lengthy description of this commit)
I spoke with Tim about this the other day -- he gave me the green
light to go ahead with this, but it turned into a bigger job than I
thought it would be. I revamped how the default RAS scheduling and
round_robin RMAPS mapping occurs. The previous algorithms were pretty
brain dead, and ignored the "slots" and "max_slots" tokens in
hostfiles. I considered this a big enough problem to fix it for the
beta (because there is currently no way to control where processes are
launched on SMPs).
There's still some more bells and whistles that I'd like to implement,
but there's no hurry, and they can go on the trunk at any time. My
patches below are for what I considered "essential", and do the
following:
- honor the "slots" and "max-slots" tokens in the hostfile (and all
their synonyms), meaning that we allocate/map until we fill slots,
and if there are still more processes to allocate/map, we keep going
until we fill max-slots (i.e., only oversubscribe a node if we have
to).
- offer two different algorithms, currently supported by two new
options to orterun. Remember that there are two parts here -- slot
allocation and process mapping. Slot allocation controls how many
processes we'll be running on a node. After that decision has been
made, process mapping effectively controls where the ranks of
MPI_COMM_WORLD (MCW) are placed. Some of the examples given below
don't make sense unless you remember that there is a difference
between the two (which makes total sense, but you have to think
about it in terms of both things):
1. "-bynode": allocates/maps one process per node in a round-robin
fashion until all slots on the node are taken. If we still have more
processes after all slots are taken, then keep going until all
max-slots are taken. Examples:
- The hostfile:
eddie slots=2 max-slots=4
vogon slots=4 max-slots=8
- orterun -bynode -np 6 -hostfile hostfile a.out
eddie: MCW ranks 0, 2
vogon: MCW ranks 1, 3, 4, 5
- orterun -bynode -np 8 -hostfile hostfile a.out
eddie: MCW ranks 0, 2, 4
vogon: MCW ranks 1, 3, 5, 6, 7
-> the algorithm oversubscribes all nodes "equally" (until each
node's max_slots is hit, of course)
- orterun -bynode -np 12 -hostfile hostfile a.out
eddie: MCW ranks 0, 2, 4, 6
vogon: MCW ranks 1, 3, 5, 7, 8, 9, 10, 11
2. "-byslot" (this is the default if you don't specify -bynode):
greedily takes all available slots on a node for a job before moving
on to the next node. If we still have processes to allocate/schedule,
then oversubscribe all nodes equally (i.e., go round robin on all
nodes until each node's max_slots is hit). Examples:
- The hostfile
eddie slots=2 max-slots=4
vogon slots=4 max-slots=8
- orterun -np 6 -hostfile hostfile a.out
eddie: MCW ranks 0, 1
vogon: MCW ranks 2, 3, 4, 5
- orterun -np 8 -hostfile hostfile a.out
eddie: MCW ranks 0, 1, 2
vogon: MCW ranks 3, 4, 5, 6, 7
-> the algorithm oversubscribes all nodes "equally" (until max_slots
is hit)
- orterun -np 12 -hostfile hostfile a.out
eddie: MCW ranks 0, 1, 2, 3
vogon: MCW ranks 4, 5, 6, 7, 8, 9, 10, 11
The above examples are fairly contrived, and it's not clear from them
that you can get different allocation answers in all cases (the
mapping differences are obvious). Consider the following allocation
example:
- The hostfile
eddie count=4
vogon count=4
earth count=4
deep-thought count=4
- orterun -np 8 -hostfile hostfile a.out
eddie: 4 slots will be allocated
vogon: 4 slots will be allocated
earth: no slots allocated
deep-thought: no slots allocated
- orterun -bynode -np 8 -hostfile hostfile a.out
eddie: 2 slots will be allocated
vogon: 2 slots will be allocated
earth: 2 slots will be allocated
deep-thought: 2 slots will be allocated
This commit was SVN r5894.
2005-05-31 16:36:53 +00:00
|
|
|
}
|
2006-07-10 14:10:21 +00:00
|
|
|
|
|
|
|
|
(copied from a mail that has a lengthy description of this commit)
I spoke with Tim about this the other day -- he gave me the green
light to go ahead with this, but it turned into a bigger job than I
thought it would be. I revamped how the default RAS scheduling and
round_robin RMAPS mapping occurs. The previous algorithms were pretty
brain dead, and ignored the "slots" and "max_slots" tokens in
hostfiles. I considered this a big enough problem to fix it for the
beta (because there is currently no way to control where processes are
launched on SMPs).
There's still some more bells and whistles that I'd like to implement,
but there's no hurry, and they can go on the trunk at any time. My
patches below are for what I considered "essential", and do the
following:
- honor the "slots" and "max-slots" tokens in the hostfile (and all
their synonyms), meaning that we allocate/map until we fill slots,
and if there are still more processes to allocate/map, we keep going
until we fill max-slots (i.e., only oversubscribe a node if we have
to).
- offer two different algorithms, currently supported by two new
options to orterun. Remember that there are two parts here -- slot
allocation and process mapping. Slot allocation controls how many
processes we'll be running on a node. After that decision has been
made, process mapping effectively controls where the ranks of
MPI_COMM_WORLD (MCW) are placed. Some of the examples given below
don't make sense unless you remember that there is a difference
between the two (which makes total sense, but you have to think
about it in terms of both things):
1. "-bynode": allocates/maps one process per node in a round-robin
fashion until all slots on the node are taken. If we still have more
processes after all slots are taken, then keep going until all
max-slots are taken. Examples:
- The hostfile:
eddie slots=2 max-slots=4
vogon slots=4 max-slots=8
- orterun -bynode -np 6 -hostfile hostfile a.out
eddie: MCW ranks 0, 2
vogon: MCW ranks 1, 3, 4, 5
- orterun -bynode -np 8 -hostfile hostfile a.out
eddie: MCW ranks 0, 2, 4
vogon: MCW ranks 1, 3, 5, 6, 7
-> the algorithm oversubscribes all nodes "equally" (until each
node's max_slots is hit, of course)
- orterun -bynode -np 12 -hostfile hostfile a.out
eddie: MCW ranks 0, 2, 4, 6
vogon: MCW ranks 1, 3, 5, 7, 8, 9, 10, 11
2. "-byslot" (this is the default if you don't specify -bynode):
greedily takes all available slots on a node for a job before moving
on to the next node. If we still have processes to allocate/schedule,
then oversubscribe all nodes equally (i.e., go round robin on all
nodes until each node's max_slots is hit). Examples:
- The hostfile
eddie slots=2 max-slots=4
vogon slots=4 max-slots=8
- orterun -np 6 -hostfile hostfile a.out
eddie: MCW ranks 0, 1
vogon: MCW ranks 2, 3, 4, 5
- orterun -np 8 -hostfile hostfile a.out
eddie: MCW ranks 0, 1, 2
vogon: MCW ranks 3, 4, 5, 6, 7
-> the algorithm oversubscribes all nodes "equally" (until max_slots
is hit)
- orterun -np 12 -hostfile hostfile a.out
eddie: MCW ranks 0, 1, 2, 3
vogon: MCW ranks 4, 5, 6, 7, 8, 9, 10, 11
The above examples are fairly contrived, and it's not clear from them
that you can get different allocation answers in all cases (the
mapping differences are obvious). Consider the following allocation
example:
- The hostfile
eddie count=4
vogon count=4
earth count=4
deep-thought count=4
- orterun -np 8 -hostfile hostfile a.out
eddie: 4 slots will be allocated
vogon: 4 slots will be allocated
earth: no slots allocated
deep-thought: no slots allocated
- orterun -bynode -np 8 -hostfile hostfile a.out
eddie: 2 slots will be allocated
vogon: 2 slots will be allocated
earth: 2 slots will be allocated
deep-thought: 2 slots will be allocated
This commit was SVN r5894.
2005-05-31 16:36:53 +00:00
|
|
|
if (ORTE_SUCCESS != rc) {
|
2006-07-10 14:10:21 +00:00
|
|
|
ORTE_ERROR_LOG(rc);
|
2005-03-14 20:57:21 +00:00
|
|
|
goto cleanup;
|
|
|
|
}
|
2006-07-11 02:59:23 +00:00
|
|
|
|
2006-10-19 18:57:29 +00:00
|
|
|
/* save the next node name bookmark as we will - in the case of mapped nodes -
|
|
|
|
* release the node information being pointed to by cur_node_item
|
|
|
|
*/
|
2006-10-20 19:00:17 +00:00
|
|
|
if(NULL != cur_node_item) {
|
|
|
|
free(save_bookmark);
|
|
|
|
save_bookmark = strdup(((orte_ras_node_t*)cur_node_item)->node_name);
|
|
|
|
}
|
2006-10-19 18:57:29 +00:00
|
|
|
|
2006-07-10 14:10:21 +00:00
|
|
|
/** cleanup the mapped_node_list, if necessary */
|
|
|
|
if (0 < app->num_map) {
|
2006-10-20 20:48:24 +00:00
|
|
|
/* we need to adjust our bookmark so it points to the node in the
|
|
|
|
* master node list - this allows the cur_node_item to "survive"
|
|
|
|
* the disassembly of the mapped_node_list
|
|
|
|
*/
|
|
|
|
if (NULL != cur_node_item) {
|
|
|
|
node = (orte_ras_node_t*)cur_node_item;
|
|
|
|
/* This can be a little tricky due to all the corner
|
|
|
|
* cases. If the mapped_node_list only has ONE entry on it, then the
|
|
|
|
* cur_node_item will always point at it, even if we used everything
|
|
|
|
* on that node. What we will do, therefore, is check the usage of the
|
|
|
|
* cur_node_item to see if it has reached the soft limit. If so, we find
|
|
|
|
* the node after that one on the master node list
|
|
|
|
*/
|
|
|
|
for (item = opal_list_get_first(&master_node_list);
|
|
|
|
item != opal_list_get_end(&master_node_list);
|
|
|
|
item = opal_list_get_next(item)) {
|
|
|
|
node2 = (orte_ras_node_t*)item;
|
|
|
|
if (0 == strcmp(node->node_name, node2->node_name)) {
|
|
|
|
if (node->node_slots <= node->node_slots_inuse) {
|
|
|
|
/* we are at or beyond the soft limit */
|
|
|
|
cur_node_item = opal_list_get_next(item);
|
|
|
|
} else {
|
|
|
|
cur_node_item = item;
|
|
|
|
}
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/* as we get rid of the mapped_node_list, we need to update
|
2006-07-10 14:10:21 +00:00
|
|
|
* corresponding entries in the master_node_list so we accurately
|
|
|
|
* track the usage of slots. Also, any node that was "used up" will have
|
|
|
|
* been removed from the mapped_node_list - we now also must ensure that
|
|
|
|
* such a node is removed from the master_node_list.
|
|
|
|
*
|
|
|
|
* Clearly, there will be a performance penalty in doing all these
|
|
|
|
* operations to maintain data integrity. However, the case where
|
|
|
|
* someone maps processes this specifically is considered the
|
|
|
|
* atypical one, so penalizing it may not be a major issue.
|
|
|
|
*
|
|
|
|
* Still, some effort to improve the efficiency of this process
|
|
|
|
* may be in order for the future.
|
2006-10-20 20:48:24 +00:00
|
|
|
*
|
2006-07-10 14:10:21 +00:00
|
|
|
*/
|
|
|
|
while (NULL != (item = opal_list_remove_first(&mapped_node_list))) {
|
|
|
|
node = (orte_ras_node_t*)item;
|
|
|
|
|
|
|
|
/** if the node was still on the mapped_node_list, then it hasn't
|
|
|
|
* been moved to the fully_used_node list - find it on the
|
|
|
|
* master_node_list and update the slots_inuse count there
|
|
|
|
*/
|
|
|
|
for (item2 = opal_list_get_first(&master_node_list);
|
|
|
|
item2 != opal_list_get_end(&master_node_list);
|
|
|
|
item2 = opal_list_get_next(item2) ) {
|
|
|
|
node2 = (orte_ras_node_t*)item2;
|
|
|
|
|
|
|
|
if (0 == strcmp(node2->node_name, node->node_name)) {
|
|
|
|
node2->node_slots_inuse = node->node_slots_inuse;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
OBJ_RELEASE(item);
|
|
|
|
}
|
|
|
|
|
|
|
|
/** that updated everything that wasn't fully used up while
|
|
|
|
* processing the specific map. Now we have to ensure that
|
|
|
|
* any nodes that were used up (and hence, transferred to the
|
|
|
|
* max_used_node list) are removed from the master_node_list
|
|
|
|
* No really nice way to do this - we just have to run through
|
|
|
|
* the two lists and remove any duplicates.
|
|
|
|
*/
|
|
|
|
while (NULL != (item = opal_list_remove_first(&max_used_nodes))) {
|
|
|
|
node = (orte_ras_node_t*)item;
|
|
|
|
|
|
|
|
for (item2 = opal_list_get_first(&master_node_list);
|
|
|
|
item2 != opal_list_get_end(&master_node_list);
|
|
|
|
item2 = opal_list_get_next(item2) ) {
|
|
|
|
node2 = (orte_ras_node_t*)item2;
|
|
|
|
|
|
|
|
/** if we have a match, then remove the entry from the
|
2006-10-20 20:48:24 +00:00
|
|
|
* master_node_list. if that entry was our bookmark,
|
|
|
|
* shift the bookmark to the next entry on the list
|
2006-07-10 14:10:21 +00:00
|
|
|
*/
|
|
|
|
if (0 == strcmp(node2->node_name, node->node_name)) {
|
2006-10-20 20:48:24 +00:00
|
|
|
if (0 == strcmp(node->node_name,
|
|
|
|
((orte_ras_node_t*)cur_node_item)->node_name)) {
|
|
|
|
cur_node_item = opal_list_get_next(item2);
|
|
|
|
}
|
2006-07-10 14:10:21 +00:00
|
|
|
opal_list_remove_item(&master_node_list, item2);
|
2006-10-20 20:48:24 +00:00
|
|
|
OBJ_RELEASE(item2);
|
2006-07-10 14:10:21 +00:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/** now put that node on the fully_used_nodes list */
|
|
|
|
opal_list_append(&fully_used_nodes, &node->super);
|
|
|
|
}
|
|
|
|
|
|
|
|
} else {
|
|
|
|
/** this mapping wasn't specified, so all we have to do is add any nodes
|
|
|
|
* that were used up in the mapping to the fully_used_nodes list - they
|
|
|
|
* were already removed from the master_node_list when we did the mapping.
|
|
|
|
*/
|
|
|
|
opal_list_join(&fully_used_nodes, opal_list_get_end(&fully_used_nodes), &max_used_nodes);
|
|
|
|
}
|
|
|
|
|
2005-03-14 20:57:21 +00:00
|
|
|
}
|
|
|
|
|
2006-12-12 16:07:23 +00:00
|
|
|
/* compute and save convenience values */
|
Compute and pass the local_rank and local number of procs (in that proc's job) on the node.
To be precise, given this hypothetical launching pattern:
host1: vpids 0, 2, 4, 6
host2: vpids 1, 3, 5, 7
The local_rank for these procs would be:
host1: vpids 0->local_rank 0, v2->lr1, v4->lr2, v6->lr3
host2: vpids 1->local_rank 0, v3->lr1, v5->lr2, v7->lr3
and the number of local procs on each node would be four. If vpid=0 then does a comm_spawn of one process on host1, the values of the parent job would remain unchanged. The local_rank of the child process would be 0 and its num_local_procs would be 1 since it is in a separate jobid.
I have verified this functionality for the rsh case - need to verify that slurm and other cases also get the right values. Some consolidation of common code is probably going to occur in the SDS components to make this simpler and more maintainable in the future.
This commit was SVN r14706.
2007-05-21 14:30:10 +00:00
|
|
|
if (ORTE_SUCCESS != (rc = orte_rmaps_base_compute_usage(map, num_procs))) {
|
|
|
|
ORTE_ERROR_LOG(rc);
|
|
|
|
goto cleanup;
|
Bring in the generalized xcast communication system along with the correspondingly revised orted launch. I will send a message out to developers explaining the basic changes. In brief:
1. generalize orte_rml.xcast to become a general broadcast-like messaging system. Messages can now be sent to any tag on the daemons or processes. Note that any message sent via xcast will be delivered to ALL processes in the specified job - you don't get to pick and choose. At a later date, we will introduce an augmented capability that will use the daemons as relays, but will allow you to send to a specified array of process names.
2. extended orte_rml.xcast so it supports more scalable message routing methodologies. At the moment, we support three: (a) direct, which sends the message directly to all recipients; (b) linear, which sends the message to the local daemon on each node, which then relays it to its own local procs; and (b) binomial, which sends the message via a binomial algo across all the daemons, each of which then relays to its own local procs. The crossover points between the algos are adjustable via MCA param, or you can simply demand that a specific algo be used.
3. orteds no longer exhibit two types of behavior: bootproxy or VM. Orteds now always behave like they are part of a virtual machine - they simply launch a job if mpirun tells them to do so. This is another step towards creating an "orteboot" functionality, but also provided a clean system for supporting message relaying.
Note one major impact of this commit: multiple daemons on a node cannot be supported any longer! Only a single daemon/node is now allowed.
This commit is known to break support for the following environments: POE, Xgrid, Xcpu, Windows. It has been tested on rsh, SLURM, and Bproc. Modifications for TM support have been made but could not be verified due to machine problems at LANL. Modifications for SGE have been made but could not be verified. The developers for the non-verified environments will be separately notified along with suggestions on how to fix the problems.
This commit was SVN r15007.
2007-06-12 13:28:54 +00:00
|
|
|
}
|
2007-07-14 15:14:07 +00:00
|
|
|
if(!opal_list_is_empty(&procs)){
|
|
|
|
if(ORTE_SUCCESS != (rc = orte_rmaps_base_rearrange_map(app, map, &procs))) {
|
|
|
|
ORTE_ERROR_LOG(rc);
|
|
|
|
goto cleanup;
|
|
|
|
}
|
|
|
|
}
|
Bring in the generalized xcast communication system along with the correspondingly revised orted launch. I will send a message out to developers explaining the basic changes. In brief:
1. generalize orte_rml.xcast to become a general broadcast-like messaging system. Messages can now be sent to any tag on the daemons or processes. Note that any message sent via xcast will be delivered to ALL processes in the specified job - you don't get to pick and choose. At a later date, we will introduce an augmented capability that will use the daemons as relays, but will allow you to send to a specified array of process names.
2. extended orte_rml.xcast so it supports more scalable message routing methodologies. At the moment, we support three: (a) direct, which sends the message directly to all recipients; (b) linear, which sends the message to the local daemon on each node, which then relays it to its own local procs; and (b) binomial, which sends the message via a binomial algo across all the daemons, each of which then relays to its own local procs. The crossover points between the algos are adjustable via MCA param, or you can simply demand that a specific algo be used.
3. orteds no longer exhibit two types of behavior: bootproxy or VM. Orteds now always behave like they are part of a virtual machine - they simply launch a job if mpirun tells them to do so. This is another step towards creating an "orteboot" functionality, but also provided a clean system for supporting message relaying.
Note one major impact of this commit: multiple daemons on a node cannot be supported any longer! Only a single daemon/node is now allowed.
This commit is known to break support for the following environments: POE, Xgrid, Xcpu, Windows. It has been tested on rsh, SLURM, and Bproc. Modifications for TM support have been made but could not be verified due to machine problems at LANL. Modifications for SGE have been made but could not be verified. The developers for the non-verified environments will be separately notified along with suggestions on how to fix the problems.
This commit was SVN r15007.
2007-06-12 13:28:54 +00:00
|
|
|
/* define the daemons that we will use for this job */
|
|
|
|
if (ORTE_SUCCESS != (rc = orte_rmaps_base_define_daemons(map))) {
|
|
|
|
ORTE_ERROR_LOG(rc);
|
|
|
|
goto cleanup;
|
2006-12-12 16:07:23 +00:00
|
|
|
}
|
|
|
|
|
2005-03-14 20:57:21 +00:00
|
|
|
/* save mapping to the registry */
|
2006-10-07 15:45:24 +00:00
|
|
|
if(ORTE_SUCCESS != (rc = orte_rmaps_base_put_job_map(map))) {
|
Compute and pass the local_rank and local number of procs (in that proc's job) on the node.
To be precise, given this hypothetical launching pattern:
host1: vpids 0, 2, 4, 6
host2: vpids 1, 3, 5, 7
The local_rank for these procs would be:
host1: vpids 0->local_rank 0, v2->lr1, v4->lr2, v6->lr3
host2: vpids 1->local_rank 0, v3->lr1, v5->lr2, v7->lr3
and the number of local procs on each node would be four. If vpid=0 then does a comm_spawn of one process on host1, the values of the parent job would remain unchanged. The local_rank of the child process would be 0 and its num_local_procs would be 1 since it is in a separate jobid.
I have verified this functionality for the rsh case - need to verify that slurm and other cases also get the right values. Some consolidation of common code is probably going to occur in the SDS components to make this simpler and more maintainable in the future.
This commit was SVN r14706.
2007-05-21 14:30:10 +00:00
|
|
|
ORTE_ERROR_LOG(rc);
|
2005-03-14 20:57:21 +00:00
|
|
|
goto cleanup;
|
|
|
|
}
|
|
|
|
|
2006-07-10 14:10:21 +00:00
|
|
|
/** join the master_node_list and fully_used_list so that all info gets updated */
|
|
|
|
opal_list_join(&master_node_list, opal_list_get_end(&master_node_list), &fully_used_nodes);
|
|
|
|
|
|
|
|
/** save the modified node information so we can start from the right
|
|
|
|
* place next time through
|
|
|
|
*/
|
|
|
|
if (ORTE_SUCCESS != (rc = orte_rmaps_base_update_node_usage(&master_node_list))) {
|
|
|
|
ORTE_ERROR_LOG(rc);
|
2006-07-10 21:25:33 +00:00
|
|
|
goto cleanup;
|
|
|
|
}
|
|
|
|
|
2006-07-11 02:59:23 +00:00
|
|
|
/** if the app_context was modified, update that information too. This can only happen
|
|
|
|
for the case where num_context=1 and the user didn't specify the number of
|
|
|
|
processes
|
|
|
|
*/
|
2006-07-10 21:25:33 +00:00
|
|
|
if (modify_app_context) {
|
2006-10-07 15:45:24 +00:00
|
|
|
if (ORTE_SUCCESS != (rc = orte_rmgr.store_app_context(jobid, map->apps, 1))) {
|
2006-07-10 21:25:33 +00:00
|
|
|
ORTE_ERROR_LOG(rc);
|
2006-10-18 20:02:16 +00:00
|
|
|
goto cleanup;
|
2006-07-10 21:25:33 +00:00
|
|
|
}
|
2006-07-10 14:10:21 +00:00
|
|
|
}
|
|
|
|
|
2006-10-18 20:02:16 +00:00
|
|
|
/* save a bookmark indicating what node we finished with so that subsequent children (if any)
|
|
|
|
* can start at the right place
|
|
|
|
*/
|
|
|
|
if (ORTE_SUCCESS != (rc = orte_rmgr.add_attribute(attributes, ORTE_RMAPS_BOOKMARK,
|
2006-10-19 18:57:29 +00:00
|
|
|
ORTE_STRING, save_bookmark,
|
2006-10-18 20:02:16 +00:00
|
|
|
ORTE_RMGR_ATTR_OVERRIDE))) {
|
|
|
|
ORTE_ERROR_LOG(rc);
|
|
|
|
}
|
2005-03-14 20:57:21 +00:00
|
|
|
|
|
|
|
cleanup:
|
2006-07-10 14:10:21 +00:00
|
|
|
while(NULL != (item = opal_list_remove_first(&master_node_list))) {
|
2005-03-14 20:57:21 +00:00
|
|
|
OBJ_RELEASE(item);
|
|
|
|
}
|
2006-07-10 14:10:21 +00:00
|
|
|
OBJ_DESTRUCT(&master_node_list);
|
2005-10-07 22:24:52 +00:00
|
|
|
|
2006-07-10 14:10:21 +00:00
|
|
|
OBJ_DESTRUCT(&max_used_nodes);
|
|
|
|
OBJ_DESTRUCT(&fully_used_nodes);
|
|
|
|
OBJ_DESTRUCT(&mapped_node_list);
|
2007-07-14 15:14:07 +00:00
|
|
|
OBJ_DESTRUCT(&procs);
|
2007-03-29 00:50:56 +00:00
|
|
|
OBJ_RELEASE(map);
|
|
|
|
|
2005-10-07 22:24:52 +00:00
|
|
|
|
2006-10-19 18:57:29 +00:00
|
|
|
free(save_bookmark);
|
|
|
|
|
2005-03-14 20:57:21 +00:00
|
|
|
return rc;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
static int orte_rmaps_rr_finalize(void)
|
|
|
|
{
|
|
|
|
return ORTE_SUCCESS;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
orte_rmaps_base_module_t orte_rmaps_round_robin_module = {
|
|
|
|
orte_rmaps_rr_map,
|
2006-10-07 15:45:24 +00:00
|
|
|
orte_rmaps_base_get_job_map,
|
|
|
|
orte_rmaps_base_get_node_map,
|
2005-03-14 20:57:21 +00:00
|
|
|
orte_rmaps_rr_finalize
|
|
|
|
};
|
|
|
|
|