2005-03-14 20:57:21 +00:00
|
|
|
/*
|
2005-11-05 19:57:48 +00:00
|
|
|
* Copyright (c) 2004-2005 The Trustees of Indiana University and Indiana
|
|
|
|
|
* University Research and Technology
|
|
|
|
|
* Corporation. All rights reserved.
|
|
|
|
|
* Copyright (c) 2004-2005 The University of Tennessee and The University
|
|
|
|
|
* of Tennessee Research Foundation. All rights
|
|
|
|
|
* reserved.
|
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.
|
2013-02-28 01:35:55 +00:00
|
|
|
* Copyright (c) 2011 Cisco Systems, Inc. All rights reserved.
|
|
|
|
|
* Copyright (c) 2011-2013 Los Alamos National Security, LLC.
|
2012-04-06 14:23:13 +00:00
|
|
|
* All rights reserved.
|
After a lot of pain, I've managed to resolve the problem of conflicting mapping directives caused by mismatched MCA params - i.e., where someone has one variant of an MCA param (e.g., rmaps_base_mapping_policy) in their default MCA param file, and then specifies another variant (e.g., --npernode) on the command line. I can't fully resolve the problem as there is no way to know precisely what the user meant - we can only guess which param was really intended since the MCA param system
can't apply its normal precedence rules.
So...print a big "deprecated" warning for the old params and error out if a conflict is detected. I know that isn't what people really wanted, but it's the best we
can do. If only the old style param is given, then process it after the warning.
Extend the current map-by param to add support for ppr and cpus-per-proc, adding the latter to the list of allowed modifiers using "pe=n" for processing elements/proc. Thus, you can map-by socket:pe=2,oversubscribe to map by socket, binding 2 processing elements/process, with oversubscription allowed. Or you can map-by ppr:2:socket:pe=4 to map two processes to every socket in the allocation, binding each process to 4 processing elements.
For those wondering, a processing element is defined as a hwthread if --use-hwthreads-as-cpus is given, or else as a core.
Refs trac:4117
This commit was SVN r30620.
The following Trac tickets were found above:
Ticket 4117 --> https://svn.open-mpi.org/trac/ompi/ticket/4117
2014-02-07 21:25:40 +00:00
|
|
|
* Copyright (c) 2014 Intel, Inc. All rights reserved.
|
2005-03-14 20:57:21 +00:00
|
|
|
* $COPYRIGHT$
|
|
|
|
|
*
|
|
|
|
|
* Additional copyrights may follow
|
|
|
|
|
*
|
|
|
|
|
* $HEADER$
|
|
|
|
|
*/
|
|
|
|
|
/** @file:
|
|
|
|
|
* rmaps framework base functionality.
|
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
#ifndef ORTE_MCA_RMAPS_BASE_H
|
|
|
|
|
#define ORTE_MCA_RMAPS_BASE_H
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* includes
|
|
|
|
|
*/
|
|
|
|
|
#include "orte_config.h"
|
2008-02-28 01:57:57 +00:00
|
|
|
#include "orte/types.h"
|
2005-03-14 20:57:21 +00:00
|
|
|
|
2005-07-03 16:22:16 +00:00
|
|
|
#include "opal/class/opal_list.h"
|
2006-02-12 01:33:29 +00:00
|
|
|
#include "opal/mca/mca.h"
|
2005-03-14 20:57:21 +00:00
|
|
|
|
2009-08-11 02:51:27 +00:00
|
|
|
#include "orte/runtime/orte_globals.h"
|
|
|
|
|
|
2006-02-12 01:33:29 +00:00
|
|
|
#include "orte/mca/rmaps/rmaps.h"
|
2005-03-14 20:57:21 +00:00
|
|
|
|
2008-02-28 01:57:57 +00:00
|
|
|
BEGIN_C_DECLS
|
2005-03-14 20:57:21 +00:00
|
|
|
|
2013-03-27 21:14:43 +00:00
|
|
|
/*
|
|
|
|
|
* MCA Framework
|
2008-06-18 03:15:56 +00:00
|
|
|
*/
|
2013-03-27 21:14:43 +00:00
|
|
|
ORTE_DECLSPEC extern mca_base_framework_t orte_rmaps_base_framework;
|
|
|
|
|
/* select a component */
|
|
|
|
|
ORTE_DECLSPEC int orte_rmaps_base_select(void);
|
2008-06-18 03:15:56 +00:00
|
|
|
|
2005-03-14 20:57:21 +00:00
|
|
|
/*
|
|
|
|
|
* Global functions for MCA overall collective open and close
|
|
|
|
|
*/
|
|
|
|
|
|
2008-02-28 01:57:57 +00:00
|
|
|
/**
|
|
|
|
|
* Struct to hold data global to the rmaps framework
|
|
|
|
|
*/
|
|
|
|
|
typedef struct {
|
2011-02-15 23:24:31 +00:00
|
|
|
/* list of selected modules */
|
|
|
|
|
opal_list_t selected_modules;
|
At long last, the fabled revision to the affinity system has arrived. A more detailed explanation of how this all works will be presented here:
https://svn.open-mpi.org/trac/ompi/wiki/ProcessPlacement
The wiki page is incomplete at the moment, but I hope to complete it over the next few days. I will provide updates on the devel list. As the wiki page states, the default and most commonly used options remain unchanged (except as noted below). New, esoteric and complex options have been added, but unless you are a true masochist, you are unlikely to use many of them beyond perhaps an initial curiosity-motivated experimentation.
In a nutshell, this commit revamps the map/rank/bind procedure to take into account topology info on the compute nodes. I have, for the most part, preserved the default behaviors, with three notable exceptions:
1. I have at long last bowed my head in submission to the system admin's of managed clusters. For years, they have complained about our default of allowing users to oversubscribe nodes - i.e., to run more processes on a node than allocated slots. Accordingly, I have modified the default behavior: if you are running off of hostfile/dash-host allocated nodes, then the default is to allow oversubscription. If you are running off of RM-allocated nodes, then the default is to NOT allow oversubscription. Flags to override these behaviors are provided, so this only affects the default behavior.
2. both cpus/rank and stride have been removed. The latter was demanded by those who didn't understand the purpose behind it - and I agreed as the users who requested it are no longer using it. The former was removed temporarily pending implementation.
3. vm launch is now the sole method for starting OMPI. It was just too darned hard to maintain multiple launch procedures - maybe someday, provided someone can demonstrate a reason to do so.
As Jeff stated, it is impossible to fully test a change of this size. I have tested it on Linux and Mac, covering all the default and simple options, singletons, and comm_spawn. That said, I'm sure others will find problems, so I'll be watching MTT results until this stabilizes.
This commit was SVN r25476.
2011-11-15 03:40:11 +00:00
|
|
|
/* default ppr */
|
|
|
|
|
char *ppr;
|
2009-08-11 02:51:27 +00:00
|
|
|
/* cpus per rank */
|
|
|
|
|
int cpus_per_rank;
|
2008-02-28 01:57:57 +00:00
|
|
|
/* display the map after it is computed */
|
|
|
|
|
bool display_map;
|
2008-07-28 14:18:36 +00:00
|
|
|
/* slot list, if provided by user */
|
|
|
|
|
char *slot_list;
|
At long last, the fabled revision to the affinity system has arrived. A more detailed explanation of how this all works will be presented here:
https://svn.open-mpi.org/trac/ompi/wiki/ProcessPlacement
The wiki page is incomplete at the moment, but I hope to complete it over the next few days. I will provide updates on the devel list. As the wiki page states, the default and most commonly used options remain unchanged (except as noted below). New, esoteric and complex options have been added, but unless you are a true masochist, you are unlikely to use many of them beyond perhaps an initial curiosity-motivated experimentation.
In a nutshell, this commit revamps the map/rank/bind procedure to take into account topology info on the compute nodes. I have, for the most part, preserved the default behaviors, with three notable exceptions:
1. I have at long last bowed my head in submission to the system admin's of managed clusters. For years, they have complained about our default of allowing users to oversubscribe nodes - i.e., to run more processes on a node than allocated slots. Accordingly, I have modified the default behavior: if you are running off of hostfile/dash-host allocated nodes, then the default is to allow oversubscription. If you are running off of RM-allocated nodes, then the default is to NOT allow oversubscription. Flags to override these behaviors are provided, so this only affects the default behavior.
2. both cpus/rank and stride have been removed. The latter was demanded by those who didn't understand the purpose behind it - and I agreed as the users who requested it are no longer using it. The former was removed temporarily pending implementation.
3. vm launch is now the sole method for starting OMPI. It was just too darned hard to maintain multiple launch procedures - maybe someday, provided someone can demonstrate a reason to do so.
As Jeff stated, it is impossible to fully test a change of this size. I have tested it on Linux and Mac, covering all the default and simple options, singletons, and comm_spawn. That said, I'm sure others will find problems, so I'll be watching MTT results until this stabilizes.
This commit was SVN r25476.
2011-11-15 03:40:11 +00:00
|
|
|
/* default mapping directives */
|
|
|
|
|
orte_mapping_policy_t mapping;
|
|
|
|
|
orte_ranking_policy_t ranking;
|
This commit introduces a new "mindist" ORTE RMAPS mapper, as well as
some relevant updates/new functionality in the opal/mca/hwloc and
orte/mca/rmaps bases. This work was mainly developed by Mellanox,
with a bunch of advice from Ralph Castain, and some minor advice from
Brice Goglin and Jeff Squyres.
Even though this is mainly Mellanox's work, Jeff is committing only
for logistical reasons (he holds the hg+svn combo tree, and can
therefore commit it directly back to SVN).
-----
Implemented distance-based mapping algorithm as a new "mindist"
component in the rmaps framework. It allows mapping processes by NUMA
due to PCI locality information as reported by the BIOS - from the
closest to device to furthest.
To use this algorithm, specify:
{{{mpirun --map-by dist:<device_name>}}}
where <device_name> can be mlx5_0, ib0, etc.
There are two modes provided:
1. bynode: load-balancing across nodes
1. byslot: go through slots sequentially (i.e., the first nodes are
more loaded)
These options are regulated by the optional ''span'' modifier; the
command line parameter looks like:
{{{mpirun --map-by dist:<device_name>,span}}}
So, for example, if there are 2 nodes, each with 8 cores, and we'd
like to run 10 processes, the mindist algorithm will place 8 processes
to the first node and 2 to the second by default. But if you want to
place 5 processes to each node, you can add a span modifier in your
command line to do that.
If there are two NUMA nodes on the node, each with 4 cores, and we run
6 processes, the mindist algorithm will try to find the NUMA closest
to the specified device, and if successful, it will place 4 processes
on that NUMA but leaving the remaining two to the next NUMA node.
You can also specify the number of cpus per MPI process. This option
is handled so that we map as many processes to the closest NUMA as we
can (number of available processors at the NUMA divided by number of
cpus per rank) and then go on with the next closest NUMA.
The default binding option for this mapping is bind-to-numa. It works
if you don't specify any binding policy. But if you specified binding
level that was "lower" than NUMA (i.e hwthread, core, socket) it would
bind to whatever level you specify.
This commit was SVN r28552.
2013-05-22 13:04:40 +00:00
|
|
|
/* device specification for min distance mapping */
|
|
|
|
|
char *device;
|
2008-02-28 01:57:57 +00:00
|
|
|
} orte_rmaps_base_t;
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* Global instance of rmaps-wide framework data
|
|
|
|
|
*/
|
|
|
|
|
ORTE_DECLSPEC extern orte_rmaps_base_t orte_rmaps_base;
|
2005-03-14 20:57:21 +00:00
|
|
|
|
2013-03-27 21:09:41 +00:00
|
|
|
/**
|
|
|
|
|
* Global MCA variables
|
|
|
|
|
*/
|
|
|
|
|
ORTE_DECLSPEC extern bool orte_rmaps_base_pernode;
|
|
|
|
|
ORTE_DECLSPEC extern int orte_rmaps_base_n_pernode;
|
|
|
|
|
ORTE_DECLSPEC extern int orte_rmaps_base_n_persocket;
|
|
|
|
|
|
2008-02-28 01:57:57 +00:00
|
|
|
/**
|
|
|
|
|
* Select an rmaps component / module
|
|
|
|
|
*/
|
2011-02-15 23:24:31 +00:00
|
|
|
typedef struct {
|
|
|
|
|
opal_list_item_t super;
|
|
|
|
|
int pri;
|
|
|
|
|
orte_rmaps_base_module_t *module;
|
|
|
|
|
mca_base_component_t *component;
|
|
|
|
|
} orte_rmaps_base_selected_module_t;
|
|
|
|
|
OBJ_CLASS_DECLARATION(orte_rmaps_base_selected_module_t);
|
|
|
|
|
|
2012-04-06 14:23:13 +00:00
|
|
|
/*
|
|
|
|
|
* Map a job
|
|
|
|
|
*/
|
|
|
|
|
ORTE_DECLSPEC void orte_rmaps_base_map_job(int fd, short args, void *cbdata);
|
|
|
|
|
|
2008-02-28 01:57:57 +00:00
|
|
|
/**
|
|
|
|
|
* Utility routines to get/set vpid mapping for the job
|
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
ORTE_DECLSPEC int orte_rmaps_base_get_vpid_range(orte_jobid_t jobid,
|
|
|
|
|
orte_vpid_t *start, orte_vpid_t *range);
|
|
|
|
|
ORTE_DECLSPEC int orte_rmaps_base_set_vpid_range(orte_jobid_t jobid,
|
|
|
|
|
orte_vpid_t start, orte_vpid_t range);
|
2005-03-14 20:57:21 +00:00
|
|
|
|
At long last, the fabled revision to the affinity system has arrived. A more detailed explanation of how this all works will be presented here:
https://svn.open-mpi.org/trac/ompi/wiki/ProcessPlacement
The wiki page is incomplete at the moment, but I hope to complete it over the next few days. I will provide updates on the devel list. As the wiki page states, the default and most commonly used options remain unchanged (except as noted below). New, esoteric and complex options have been added, but unless you are a true masochist, you are unlikely to use many of them beyond perhaps an initial curiosity-motivated experimentation.
In a nutshell, this commit revamps the map/rank/bind procedure to take into account topology info on the compute nodes. I have, for the most part, preserved the default behaviors, with three notable exceptions:
1. I have at long last bowed my head in submission to the system admin's of managed clusters. For years, they have complained about our default of allowing users to oversubscribe nodes - i.e., to run more processes on a node than allocated slots. Accordingly, I have modified the default behavior: if you are running off of hostfile/dash-host allocated nodes, then the default is to allow oversubscription. If you are running off of RM-allocated nodes, then the default is to NOT allow oversubscription. Flags to override these behaviors are provided, so this only affects the default behavior.
2. both cpus/rank and stride have been removed. The latter was demanded by those who didn't understand the purpose behind it - and I agreed as the users who requested it are no longer using it. The former was removed temporarily pending implementation.
3. vm launch is now the sole method for starting OMPI. It was just too darned hard to maintain multiple launch procedures - maybe someday, provided someone can demonstrate a reason to do so.
As Jeff stated, it is impossible to fully test a change of this size. I have tested it on Linux and Mac, covering all the default and simple options, singletons, and comm_spawn. That said, I'm sure others will find problems, so I'll be watching MTT results until this stabilizes.
This commit was SVN r25476.
2011-11-15 03:40:11 +00:00
|
|
|
/* pretty-print functions */
|
|
|
|
|
ORTE_DECLSPEC char* orte_rmaps_base_print_mapping(orte_mapping_policy_t mapping);
|
|
|
|
|
ORTE_DECLSPEC char* orte_rmaps_base_print_ranking(orte_ranking_policy_t ranking);
|
|
|
|
|
|
|
|
|
|
#if OPAL_HAVE_HWLOC
|
|
|
|
|
ORTE_DECLSPEC int orte_rmaps_base_prep_topology(hwloc_topology_t topo);
|
|
|
|
|
#endif
|
|
|
|
|
|
2011-12-14 20:01:15 +00:00
|
|
|
ORTE_DECLSPEC int orte_rmaps_base_filter_nodes(orte_app_context_t *app,
|
|
|
|
|
opal_list_t *nodes,
|
|
|
|
|
bool remove);
|
|
|
|
|
|
2013-12-20 20:42:39 +00:00
|
|
|
ORTE_DECLSPEC int orte_rmaps_base_set_mapping_policy(orte_mapping_policy_t *policy,
|
|
|
|
|
char **device, char *spec);
|
|
|
|
|
ORTE_DECLSPEC int orte_rmaps_base_set_ranking_policy(orte_ranking_policy_t *policy,
|
|
|
|
|
orte_mapping_policy_t mapping,
|
|
|
|
|
char *spec);
|
|
|
|
|
|
2008-02-28 01:57:57 +00:00
|
|
|
END_C_DECLS
|
2005-03-14 20:57:21 +00:00
|
|
|
|
|
|
|
|
#endif
|