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 .
2011-06-23 20:38:02 +00:00
* Copyright ( c ) 2004 - 2011 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 .
2014-01-22 12:17:14 +00:00
* Copyright ( c ) 2006 - 2014 Cisco Systems , Inc . All rights reserved .
2013-02-28 01:35:55 +00:00
* Copyright ( c ) 2011 - 2013 Los Alamos National Security , LLC .
2012-04-06 14:23:13 +00:00
* All rights reserved .
2014-02-11 02:53:53 +00:00
* Copyright ( c ) 2014 Intel , Inc . All rights reserved .
2014-08-11 03:22:05 +00:00
* Copyright ( c ) 2014 Research Organization for Information Science
* and Technology ( RIST ) . All rights reserved .
2005-03-14 20:57:21 +00:00
* $ COPYRIGHT $
*
* Additional copyrights may follow
*
* $ HEADER $
*/
# include "orte_config.h"
2008-02-28 01:57:57 +00:00
# include "orte/constants.h"
2005-03-14 20:57:21 +00:00
2009-04-29 00:49:23 +00:00
# ifdef HAVE_STRING_H
# include <string.h>
# endif
2006-02-12 01:33:29 +00:00
# include "opal/mca/mca.h"
2013-04-29 17:02:37 +00:00
# include "opal/util/argv.h"
2009-02-14 02:26:12 +00:00
# include "opal/util/output.h"
2006-02-12 01:33:29 +00:00
# include "opal/mca/base/base.h"
2005-03-14 20:57:21 +00:00
2009-08-11 02:51:27 +00:00
# include "orte/runtime/orte_globals.h"
2009-10-13 04:19:07 +00:00
# include "orte/util/show_help.h"
2013-06-27 03:04:50 +00:00
# include "orte/mca/errmgr/errmgr.h"
2006-10-03 17:40:00 +00:00
2006-09-14 21:29:51 +00:00
# include "orte/mca/rmaps/base/rmaps_private.h"
2006-02-12 01:33:29 +00:00
# include "orte/mca/rmaps/base/base.h"
2005-03-14 20:57:21 +00:00
/*
* The following file was created by configure . It contains extern
* statements and the definition of an array of pointers to each
* component ' s public mca_base_component_t struct .
*/
2005-07-04 18:24:58 +00:00
# include "orte/mca/rmaps/base/static-components.h"
2005-03-14 20:57:21 +00:00
/*
2006-09-14 21:29:51 +00:00
* Global variables
2005-03-14 20:57:21 +00:00
*/
2006-09-14 21:29:51 +00:00
orte_rmaps_base_t orte_rmaps_base ;
2013-03-27 21:09:41 +00:00
bool orte_rmaps_base_pernode = false ;
int orte_rmaps_base_n_pernode = 0 ;
int orte_rmaps_base_n_persocket = 0 ;
/*
* Local variables
*/
static char * rmaps_base_mapping_policy = NULL ;
static char * rmaps_base_ranking_policy = NULL ;
2014-01-02 04:16:43 +00:00
static bool rmaps_base_bycore = false ;
2013-03-27 21:09:41 +00:00
static bool rmaps_base_byslot = false ;
static bool rmaps_base_bynode = false ;
static bool rmaps_base_no_schedule_local = false ;
static bool rmaps_base_no_oversubscribe = false ;
static bool rmaps_base_oversubscribe = false ;
static bool rmaps_base_display_devel_map = false ;
static bool rmaps_base_display_diffable_map = false ;
2013-06-27 03:04:50 +00:00
static char * rmaps_base_topo_file = NULL ;
2013-03-27 21:09:41 +00:00
2013-03-27 21:14:43 +00:00
static int orte_rmaps_base_register ( mca_base_register_flag_t flags )
2013-03-27 21:09:41 +00:00
{
int var_id ;
orte_rmaps_base_pernode = false ;
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
var_id = mca_base_var_register ( " orte " , " rmaps " , " base " , " pernode " ,
2013-03-27 21:09:41 +00:00
" Launch one ppn as directed " ,
MCA_BASE_VAR_TYPE_BOOL , NULL , 0 , 0 ,
OPAL_INFO_LVL_9 ,
MCA_BASE_VAR_SCOPE_READONLY ,
& orte_rmaps_base_pernode ) ;
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
( void ) mca_base_var_register_synonym ( var_id , " orte " , " rmaps " , " ppr " , " pernode " , 0 ) ;
2013-03-27 21:09:41 +00:00
orte_rmaps_base_n_pernode = 0 ;
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
var_id = mca_base_var_register ( " orte " , " rmaps " , " base " , " n_pernode " ,
2013-03-27 21:09:41 +00:00
" Launch n procs/node " , MCA_BASE_VAR_TYPE_INT ,
2014-01-15 14:48:39 +00:00
NULL , 0 , 0 ,
OPAL_INFO_LVL_9 ,
2013-03-27 21:09:41 +00:00
MCA_BASE_VAR_SCOPE_READONLY , & orte_rmaps_base_n_pernode ) ;
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
( void ) mca_base_var_register_synonym ( var_id , " orte " , " rmaps " , " ppr " , " n_pernode " , 0 ) ;
2013-03-27 21:09:41 +00:00
orte_rmaps_base_n_persocket = 0 ;
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
var_id = mca_base_var_register ( " orte " , " rmaps " , " base " , " n_persocket " ,
2013-03-27 21:09:41 +00:00
" Launch n procs/socket " , MCA_BASE_VAR_TYPE_INT ,
2014-01-15 14:48:39 +00:00
NULL , 0 , 0 ,
OPAL_INFO_LVL_9 ,
2013-03-27 21:09:41 +00:00
MCA_BASE_VAR_SCOPE_READONLY , & orte_rmaps_base_n_persocket ) ;
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
( void ) mca_base_var_register_synonym ( var_id , " orte " , " rmaps " , " ppr " , " n_persocket " , 0 ) ;
2013-03-27 21:09:41 +00:00
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
orte_rmaps_base . ppr = NULL ;
var_id = mca_base_var_register ( " orte " , " rmaps " , " base " , " pattern " ,
2013-03-27 21:09:41 +00:00
" Comma-separated list of number of processes on a given resource type [default: none] " ,
MCA_BASE_VAR_TYPE_STRING , NULL , 0 , 0 , OPAL_INFO_LVL_9 ,
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
MCA_BASE_VAR_SCOPE_READONLY , & orte_rmaps_base . ppr ) ;
( void ) mca_base_var_register_synonym ( var_id , " orte " , " rmaps " , " ppr " , " pattern " , 0 ) ;
2013-03-27 21:09:41 +00:00
/* define default mapping policy */
rmaps_base_mapping_policy = NULL ;
var_id = mca_base_var_register ( " orte " , " rmaps " , " base " , " mapping_policy " ,
# if OPAL_HAVE_HWLOC
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
" Mapping Policy [slot | hwthread | core (default:np<=2) | l1cache | l2cache | l3cache | socket (default:np>2) | numa | board | node | seq | dist | ppr], with allowed modifiers :PE=y,SPAN,OVERSUBSCRIBE,NOOVERSUBSCRIBE " ,
2013-03-27 21:09:41 +00:00
# else
" Mapping Policy [slot (default) | node], with allowed modifiers :SPAN,OVERSUBSCRIBE,NOOVERSUBSCRIBE " ,
# endif
MCA_BASE_VAR_TYPE_STRING , NULL , 0 , 0 ,
OPAL_INFO_LVL_9 ,
MCA_BASE_VAR_SCOPE_READONLY ,
& rmaps_base_mapping_policy ) ;
( void ) mca_base_var_register_synonym ( var_id , " orte " , " rmaps " , " base " , " schedule_policy " ,
MCA_BASE_VAR_SYN_FLAG_DEPRECATED ) ;
/* define default ranking policy */
rmaps_base_ranking_policy = NULL ;
( void ) mca_base_var_register ( " orte " , " rmaps " , " base " , " ranking_policy " ,
# if OPAL_HAVE_HWLOC
2013-12-15 17:25:54 +00:00
" Ranking Policy [slot (default:np<=2) | hwthread | core | l1cache | l2cache | l3cache | socket (default:np>2) | numa | board | node], with modifier :SPAN or :FILL " ,
2013-03-27 21:09:41 +00:00
# else
" Ranking Policy [slot (default) | node] " ,
# endif
MCA_BASE_VAR_TYPE_STRING , NULL , 0 , 0 ,
OPAL_INFO_LVL_9 ,
MCA_BASE_VAR_SCOPE_READONLY ,
& rmaps_base_ranking_policy ) ;
/* backward compatibility */
2014-01-02 04:16:43 +00:00
rmaps_base_bycore = false ;
( void ) mca_base_var_register ( " orte " , " rmaps " , " base " , " bycore " ,
" Whether to map and rank processes round-robin by core " ,
MCA_BASE_VAR_TYPE_BOOL , NULL , 0 , 0 ,
OPAL_INFO_LVL_9 ,
MCA_BASE_VAR_SCOPE_READONLY , & rmaps_base_bycore ) ;
2013-03-27 21:09:41 +00:00
rmaps_base_byslot = false ;
( void ) mca_base_var_register ( " orte " , " rmaps " , " base " , " byslot " ,
" Whether to map and rank processes round-robin by slot " ,
MCA_BASE_VAR_TYPE_BOOL , NULL , 0 , 0 ,
OPAL_INFO_LVL_9 ,
MCA_BASE_VAR_SCOPE_READONLY , & rmaps_base_byslot ) ;
rmaps_base_bynode = false ;
( void ) mca_base_var_register ( " orte " , " rmaps " , " base " , " bynode " ,
" Whether to map and rank processes round-robin by node " ,
MCA_BASE_VAR_TYPE_BOOL , NULL , 0 , 0 ,
OPAL_INFO_LVL_9 ,
MCA_BASE_VAR_SCOPE_READONLY , & rmaps_base_bynode ) ;
/* #cpus/rank to use */
orte_rmaps_base . cpus_per_rank = 1 ;
# if OPAL_HAVE_HWLOC
var_id = mca_base_var_register ( " orte " , " rmaps " , " base " , " cpus_per_proc " ,
" Number of cpus to use for each rank [1-2**15 (default=1)] " ,
MCA_BASE_VAR_TYPE_INT , NULL , 0 , 0 ,
OPAL_INFO_LVL_9 ,
MCA_BASE_VAR_SCOPE_READONLY , & orte_rmaps_base . cpus_per_rank ) ;
mca_base_var_register_synonym ( var_id , " orte " , " rmaps " , " base " , " cpus_per_rank " , 0 ) ;
# endif
rmaps_base_no_schedule_local = false ;
( void ) mca_base_var_register ( " orte " , " rmaps " , " base " , " no_schedule_local " ,
" If false, allow scheduling MPI applications on the same node as mpirun (default). If true, do not schedule any MPI applications on the same node as mpirun " ,
MCA_BASE_VAR_TYPE_BOOL , NULL , 0 , 0 ,
OPAL_INFO_LVL_9 ,
MCA_BASE_VAR_SCOPE_READONLY , & rmaps_base_no_schedule_local ) ;
/** default condition that allows oversubscription */
rmaps_base_no_oversubscribe = false ;
( void ) mca_base_var_register ( " orte " , " rmaps " , " base " , " no_oversubscribe " ,
" If true, then do not allow oversubscription of nodes - mpirun will return an error if there aren't enough nodes to launch all processes without oversubscribing " ,
MCA_BASE_VAR_TYPE_BOOL , NULL , 0 , 0 ,
OPAL_INFO_LVL_9 ,
MCA_BASE_VAR_SCOPE_READONLY , & rmaps_base_no_oversubscribe ) ;
rmaps_base_oversubscribe = false ;
( void ) mca_base_var_register ( " orte " , " rmaps " , " base " , " oversubscribe " ,
2014-06-24 18:11:39 +00:00
" If true, then allow oversubscription of nodes and overloading of processing elements " ,
2013-03-27 21:09:41 +00:00
MCA_BASE_VAR_TYPE_BOOL , NULL , 0 , 0 ,
OPAL_INFO_LVL_9 ,
MCA_BASE_VAR_SCOPE_READONLY , & rmaps_base_oversubscribe ) ;
/* should we display the map after determining it? */
orte_rmaps_base . display_map = false ;
( void ) mca_base_var_register ( " orte " , " rmaps " , " base " , " display_map " ,
" Whether to display the process map after it is computed " ,
MCA_BASE_VAR_TYPE_BOOL , NULL , 0 , 0 ,
OPAL_INFO_LVL_9 ,
MCA_BASE_VAR_SCOPE_READONLY , & orte_rmaps_base . display_map ) ;
rmaps_base_display_devel_map = false ;
( void ) mca_base_var_register ( " orte " , " rmaps " , " base " , " display_devel_map " ,
" Whether to display a developer-detail process map after it is computed " ,
MCA_BASE_VAR_TYPE_BOOL , NULL , 0 , 0 ,
OPAL_INFO_LVL_9 ,
MCA_BASE_VAR_SCOPE_READONLY , & rmaps_base_display_devel_map ) ;
/* should we display the topology along with the map? */
orte_display_topo_with_map = false ;
( void ) mca_base_var_register ( " orte " , " rmaps " , " base " , " display_topo_with_map " ,
" Whether to display the topology with the map " ,
MCA_BASE_VAR_TYPE_BOOL , NULL , 0 , 0 ,
OPAL_INFO_LVL_9 ,
MCA_BASE_VAR_SCOPE_READONLY , & orte_display_topo_with_map ) ;
rmaps_base_display_diffable_map = false ;
( void ) mca_base_var_register ( " orte " , " rmaps " , " base " , " display_diffable_map " ,
" Whether to display a diffable process map after it is computed " ,
MCA_BASE_VAR_TYPE_BOOL , NULL , 0 , 0 ,
OPAL_INFO_LVL_9 ,
MCA_BASE_VAR_SCOPE_READONLY , & rmaps_base_display_diffable_map ) ;
2013-06-27 03:04:50 +00:00
rmaps_base_topo_file = NULL ;
( void ) mca_base_var_register ( " orte " , " rmaps " , " base " , " topology " ,
" hwloc topology file (xml format) describing the topology of the compute nodes [default: none] " ,
MCA_BASE_VAR_TYPE_STRING , NULL , 0 , 0 , OPAL_INFO_LVL_9 ,
MCA_BASE_VAR_SCOPE_READONLY , & rmaps_base_topo_file ) ;
2013-03-27 21:09:41 +00:00
return ORTE_SUCCESS ;
}
2005-03-14 20:57:21 +00:00
2013-03-27 21:14:43 +00:00
static int orte_rmaps_base_close ( void )
{
opal_list_item_t * item ;
/* cleanup globals */
while ( NULL ! = ( item = opal_list_remove_first ( & orte_rmaps_base . selected_modules ) ) ) {
OBJ_RELEASE ( item ) ;
}
OBJ_DESTRUCT ( & orte_rmaps_base . selected_modules ) ;
return mca_base_framework_components_close ( & orte_rmaps_base_framework , NULL ) ;
}
2005-03-14 20:57:21 +00:00
/**
* Function for finding and opening either all MCA components , or the one
* that was specifically requested via a MCA parameter .
*/
2013-03-27 21:14:43 +00:00
static int orte_rmaps_base_open ( mca_base_open_flag_t flags )
2005-03-14 20:57:21 +00:00
{
2013-12-20 20:42:39 +00:00
int rc ;
2005-03-14 20:57:21 +00:00
2008-02-28 01:57:57 +00:00
/* init the globals */
2011-02-15 23:24:31 +00:00
OBJ_CONSTRUCT ( & orte_rmaps_base . selected_modules , opal_list_t ) ;
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
orte_rmaps_base . slot_list = NULL ;
orte_rmaps_base . mapping = 0 ;
orte_rmaps_base . ranking = 0 ;
2011-02-15 23:24:31 +00:00
2013-07-12 17:21:14 +00:00
# if OPAL_HAVE_HWLOC
2013-06-27 03:04:50 +00:00
/* if a topology file was given, then set our topology
* from it . Even though our actual topology may differ ,
* mpirun only needs to see the compute node topology
* for mapping purposes
*/
if ( NULL ! = rmaps_base_topo_file ) {
if ( OPAL_SUCCESS ! = ( rc = opal_hwloc_base_set_topology ( rmaps_base_topo_file ) ) ) {
orte_show_help ( " help-orte-rmaps-base.txt " , " topo-file " , true , rmaps_base_topo_file ) ;
return ORTE_ERR_SILENT ;
}
}
2013-07-12 17:21:14 +00:00
# endif
2013-06-27 03:04:50 +00:00
2014-02-11 02:53:53 +00:00
/* check for violations that has to be detected before we parse the mapping option */
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
if ( NULL ! = orte_rmaps_base . ppr ) {
orte_show_help ( " help-orte-rmaps-base.txt " , " deprecated " , true ,
" --ppr, -ppr " , " --map-by ppr:<pattern> " ,
" rmaps_base_pattern, rmaps_ppr_pattern " ,
" rmaps_base_mapping_policy=ppr:<pattern> " ) ;
/* if the mapping policy is NULL, then we can proceed */
if ( NULL = = rmaps_base_mapping_policy ) {
asprintf ( & rmaps_base_mapping_policy , " ppr:%s " , orte_rmaps_base . ppr ) ;
} else {
return ORTE_ERR_SILENT ;
}
}
2014-02-11 02:53:53 +00:00
if ( 1 < orte_rmaps_base . cpus_per_rank ) {
orte_show_help ( " help-orte-rmaps-base.txt " , " deprecated " , true ,
" --cpus-per-proc, -cpus-per-proc, --cpus-per-rank, -cpus-per-rank " ,
2014-06-08 20:26:59 +00:00
" --map-by <obj>:PE=N, default <obj>=NUMA " ,
" rmaps_base_cpus_per_proc " , " rmaps_base_mapping_policy=<obj>:PE=N, default <obj>=NUMA " ) ;
2014-02-11 02:53:53 +00:00
}
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
2013-12-20 20:42:39 +00:00
if ( ORTE_SUCCESS ! = ( rc = orte_rmaps_base_set_mapping_policy ( & orte_rmaps_base . mapping ,
& orte_rmaps_base . device ,
rmaps_base_mapping_policy ) ) ) {
return rc ;
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
}
2013-12-20 20:42:39 +00:00
if ( ORTE_SUCCESS ! = ( rc = orte_rmaps_base_set_ranking_policy ( & orte_rmaps_base . ranking ,
orte_rmaps_base . mapping ,
rmaps_base_ranking_policy ) ) ) {
return rc ;
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
}
2014-02-11 03:05:26 +00:00
if ( rmaps_base_bycore ) {
2014-01-15 14:48:39 +00:00
orte_show_help ( " help-orte-rmaps-base.txt " , " deprecated " , true ,
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
" --bycore, -bycore " , " --map-by core " ,
2014-01-15 14:48:39 +00:00
" rmaps_base_bycore " , " rmaps_base_mapping_policy=core " ) ;
2014-01-02 04:16:43 +00:00
/* set mapping policy to bycore - error if something else already set */
if ( ( ORTE_MAPPING_GIVEN & ORTE_GET_MAPPING_DIRECTIVE ( orte_rmaps_base . mapping ) ) & &
ORTE_GET_MAPPING_POLICY ( orte_rmaps_base . mapping ) ! = ORTE_MAPPING_BYCORE ) {
/* error - cannot redefine the default mapping policy */
orte_show_help ( " help-orte-rmaps-base.txt " , " redefining-policy " , true , " mapping " ,
" bycore " , orte_rmaps_base_print_mapping ( orte_rmaps_base . mapping ) ) ;
return ORTE_ERR_SILENT ;
}
ORTE_SET_MAPPING_POLICY ( orte_rmaps_base . mapping , ORTE_MAPPING_BYCORE ) ;
ORTE_SET_MAPPING_DIRECTIVE ( orte_rmaps_base . mapping , ORTE_MAPPING_GIVEN ) ;
/* set ranking policy to bycore - error if something else already set */
if ( ( ORTE_RANKING_GIVEN & ORTE_GET_RANKING_DIRECTIVE ( orte_rmaps_base . ranking ) ) & &
ORTE_GET_RANKING_POLICY ( orte_rmaps_base . ranking ) ! = ORTE_RANK_BY_CORE ) {
/* error - cannot redefine the default ranking policy */
orte_show_help ( " help-orte-rmaps-base.txt " , " redefining-policy " , true , " ranking " ,
" bycore " , orte_rmaps_base_print_ranking ( orte_rmaps_base . ranking ) ) ;
return ORTE_ERR_SILENT ;
}
ORTE_SET_RANKING_POLICY ( orte_rmaps_base . ranking , ORTE_RANK_BY_CORE ) ;
ORTE_SET_RANKING_DIRECTIVE ( orte_rmaps_base . ranking , ORTE_RANKING_GIVEN ) ;
}
2013-03-27 21:09:41 +00:00
if ( rmaps_base_byslot ) {
2014-01-15 14:48:39 +00:00
orte_show_help ( " help-orte-rmaps-base.txt " , " deprecated " , true ,
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
" --byslot, -byslot " , " --map-by slot " ,
2014-01-15 14:48:39 +00:00
" rmaps_base_byslot " , " rmaps_base_mapping_policy=slot " ) ;
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
/* set mapping policy to byslot - error if something else already set */
if ( ( ORTE_MAPPING_GIVEN & ORTE_GET_MAPPING_DIRECTIVE ( orte_rmaps_base . mapping ) ) & &
ORTE_GET_MAPPING_POLICY ( orte_rmaps_base . mapping ) ! = ORTE_MAPPING_BYSLOT ) {
/* error - cannot redefine the default mapping policy */
orte_show_help ( " help-orte-rmaps-base.txt " , " redefining-policy " , true , " mapping " ,
" byslot " , orte_rmaps_base_print_mapping ( orte_rmaps_base . mapping ) ) ;
return ORTE_ERR_SILENT ;
}
ORTE_SET_MAPPING_POLICY ( orte_rmaps_base . mapping , ORTE_MAPPING_BYSLOT ) ;
ORTE_SET_MAPPING_DIRECTIVE ( orte_rmaps_base . mapping , ORTE_MAPPING_GIVEN ) ;
/* set ranking policy to byslot - error if something else already set */
if ( ( ORTE_RANKING_GIVEN & ORTE_GET_RANKING_DIRECTIVE ( orte_rmaps_base . ranking ) ) & &
ORTE_GET_RANKING_POLICY ( orte_rmaps_base . ranking ) ! = ORTE_RANK_BY_SLOT ) {
/* error - cannot redefine the default ranking policy */
orte_show_help ( " help-orte-rmaps-base.txt " , " redefining-policy " , true , " ranking " ,
" byslot " , orte_rmaps_base_print_ranking ( orte_rmaps_base . ranking ) ) ;
return ORTE_ERR_SILENT ;
}
ORTE_SET_RANKING_POLICY ( orte_rmaps_base . ranking , ORTE_RANK_BY_SLOT ) ;
ORTE_SET_RANKING_DIRECTIVE ( orte_rmaps_base . ranking , ORTE_RANKING_GIVEN ) ;
}
2013-03-27 21:09:41 +00:00
if ( rmaps_base_bynode ) {
2014-01-15 14:48:39 +00:00
orte_show_help ( " help-orte-rmaps-base.txt " , " deprecated " , true ,
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
" --bynode, -bynode " , " --map-by node " ,
2014-01-15 14:48:39 +00:00
" rmaps_base_bynode " , " rmaps_base_mapping_policy=node " ) ;
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
/* set mapping policy to bynode - error if something else already set */
if ( ( ORTE_MAPPING_GIVEN & ORTE_GET_MAPPING_DIRECTIVE ( orte_rmaps_base . mapping ) ) & &
ORTE_GET_MAPPING_POLICY ( orte_rmaps_base . mapping ) ! = ORTE_MAPPING_BYNODE ) {
orte_show_help ( " help-orte-rmaps-base.txt " , " redefining-policy " , true , " mapping " ,
" bynode " , orte_rmaps_base_print_mapping ( orte_rmaps_base . mapping ) ) ;
return ORTE_ERR_SILENT ;
}
ORTE_SET_MAPPING_POLICY ( orte_rmaps_base . mapping , ORTE_MAPPING_BYNODE ) ;
ORTE_SET_MAPPING_DIRECTIVE ( orte_rmaps_base . mapping , ORTE_MAPPING_GIVEN ) ;
/* set ranking policy to bynode - error if something else already set */
if ( ( ORTE_RANKING_GIVEN & ORTE_GET_RANKING_DIRECTIVE ( orte_rmaps_base . ranking ) ) & &
ORTE_GET_RANKING_POLICY ( orte_rmaps_base . ranking ) ! = ORTE_RANK_BY_NODE ) {
/* error - cannot redefine the default ranking policy */
orte_show_help ( " help-orte-rmaps-base.txt " , " redefining-policy " , true , " ranking " ,
" bynode " , orte_rmaps_base_print_ranking ( orte_rmaps_base . ranking ) ) ;
return ORTE_ERR_SILENT ;
}
ORTE_SET_RANKING_POLICY ( orte_rmaps_base . ranking , ORTE_RANK_BY_NODE ) ;
ORTE_SET_RANKING_DIRECTIVE ( orte_rmaps_base . ranking , ORTE_RANKING_GIVEN ) ;
2005-10-07 22:24:52 +00:00
}
2014-01-27 22:40:51 +00:00
if ( 1 < orte_rmaps_base . cpus_per_rank ) {
2014-01-28 17:10:32 +00:00
# if OPAL_HAVE_HWLOC
2014-01-27 22:40:51 +00:00
/* if we were asked for multiple cpus/proc, then we have to
* bind to those cpus - any other binding policy is an
* error
*/
2014-02-26 18:12:23 +00:00
if ( OPAL_BINDING_POLICY_IS_SET ( opal_hwloc_binding_policy ) ) {
2014-02-11 03:05:26 +00:00
if ( opal_hwloc_use_hwthreads_as_cpus ) {
if ( OPAL_BIND_TO_HWTHREAD ! = OPAL_GET_BINDING_POLICY ( opal_hwloc_binding_policy ) ) {
orte_show_help ( " help-orte-rmaps-base.txt " , " mismatch-binding " , true ,
orte_rmaps_base . cpus_per_rank , " use-hwthreads-as-cpus " ,
opal_hwloc_base_print_binding ( opal_hwloc_binding_policy ) ,
" bind-to hwthread " ) ;
return ORTE_ERR_SILENT ;
}
2014-01-27 22:40:51 +00:00
} else if ( OPAL_BIND_TO_CORE ! = OPAL_GET_BINDING_POLICY ( opal_hwloc_binding_policy ) ) {
orte_show_help ( " help-orte-rmaps-base.txt " , " mismatch-binding " , true ,
orte_rmaps_base . cpus_per_rank , " cores as cpus " ,
opal_hwloc_base_print_binding ( opal_hwloc_binding_policy ) ,
" bind-to core " ) ;
return ORTE_ERR_SILENT ;
}
2014-02-26 18:12:23 +00:00
} else {
if ( opal_hwloc_use_hwthreads_as_cpus ) {
OPAL_SET_BINDING_POLICY ( opal_hwloc_binding_policy , OPAL_BIND_TO_HWTHREAD ) ;
} else {
OPAL_SET_BINDING_POLICY ( opal_hwloc_binding_policy , OPAL_BIND_TO_CORE ) ;
}
2014-01-27 22:40:51 +00:00
}
2014-06-08 20:26:59 +00:00
/* we also need to ensure we are mapping to a high-enough level to have
* multiple cpus beneath it - by default , we ' ll go to the NUMA level */
if ( ORTE_MAPPING_GIVEN & ORTE_GET_MAPPING_DIRECTIVE ( orte_rmaps_base . mapping ) ) {
2014-06-13 16:32:52 +00:00
if ( ORTE_GET_MAPPING_POLICY ( orte_rmaps_base . mapping ) = = ORTE_MAPPING_BYHWTHREAD | |
( ORTE_GET_MAPPING_POLICY ( orte_rmaps_base . mapping ) = = ORTE_MAPPING_BYCORE & &
! opal_hwloc_use_hwthreads_as_cpus ) ) {
2014-06-08 20:26:59 +00:00
orte_show_help ( " help-orte-rmaps-base.txt " , " mapping-too-low-init " , true ) ;
return ORTE_ERR_SILENT ;
}
} else {
opal_output_verbose ( 5 , orte_rmaps_base_framework . framework_output ,
" %s rmaps:base pe/rank set - setting mapping to BYNUMA " ,
ORTE_NAME_PRINT ( ORTE_PROC_MY_NAME ) ) ;
ORTE_SET_MAPPING_POLICY ( orte_rmaps_base . mapping , ORTE_MAPPING_BYNUMA ) ;
ORTE_SET_MAPPING_DIRECTIVE ( orte_rmaps_base . mapping , ORTE_MAPPING_GIVEN ) ;
}
2014-01-28 17:10:32 +00:00
# endif
2014-01-27 22:40:51 +00:00
}
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
if ( orte_rmaps_base_pernode ) {
orte_show_help ( " help-orte-rmaps-base.txt " , " deprecated " , true ,
2014-02-26 18:12:23 +00:00
" --pernode, -pernode " , " --map-by ppr:1:node " ,
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
" rmaps_base_pernode, rmaps_ppr_pernode " ,
2014-02-26 18:12:23 +00:00
" rmaps_base_mapping_policy=ppr:1:node " ) ;
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
/* there is no way to resolve this conflict, so if something else was
* given , we have no choice but to error out
*/
if ( ORTE_MAPPING_GIVEN & ORTE_GET_MAPPING_DIRECTIVE ( orte_rmaps_base . mapping ) ) {
orte_show_help ( " help-orte-rmaps-base.txt " , " redefining-policy " , true , " mapping " ,
" bynode " , orte_rmaps_base_print_mapping ( orte_rmaps_base . mapping ) ) ;
return ORTE_ERR_SILENT ;
}
/* ensure we set the mapping policy to ppr */
ORTE_SET_MAPPING_POLICY ( orte_rmaps_base . mapping , ORTE_MAPPING_PPR ) ;
ORTE_SET_MAPPING_DIRECTIVE ( orte_rmaps_base . mapping , ORTE_MAPPING_GIVEN ) ;
/* define the ppr */
orte_rmaps_base . ppr = strdup ( " 1:node " ) ;
}
if ( 0 < orte_rmaps_base_n_pernode ) {
orte_show_help ( " help-orte-rmaps-base.txt " , " deprecated " , true ,
2014-02-26 18:12:23 +00:00
" --npernode, -npernode " , " --map-by ppr:N:node " ,
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
" rmaps_base_n_pernode, rmaps_ppr_n_pernode " ,
2014-02-26 18:12:23 +00:00
" rmaps_base_mapping_policy=ppr:N:node " ) ;
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
/* there is no way to resolve this conflict, so if something else was
* given , we have no choice but to error out
*/
if ( ORTE_MAPPING_GIVEN & ORTE_GET_MAPPING_DIRECTIVE ( orte_rmaps_base . mapping ) ) {
orte_show_help ( " help-orte-rmaps-base.txt " , " redefining-policy " , true , " mapping " ,
" bynode " , orte_rmaps_base_print_mapping ( orte_rmaps_base . mapping ) ) ;
return ORTE_ERR_SILENT ;
}
/* ensure we set the mapping policy to ppr */
ORTE_SET_MAPPING_POLICY ( orte_rmaps_base . mapping , ORTE_MAPPING_PPR ) ;
ORTE_SET_MAPPING_DIRECTIVE ( orte_rmaps_base . mapping , ORTE_MAPPING_GIVEN ) ;
/* define the ppr */
asprintf ( & orte_rmaps_base . ppr , " %d:node " , orte_rmaps_base_n_pernode ) ;
}
if ( 0 < orte_rmaps_base_n_persocket ) {
orte_show_help ( " help-orte-rmaps-base.txt " , " deprecated " , true ,
2014-02-26 18:12:23 +00:00
" --npersocket, -npersocket " , " --map-by ppr:N:socket " ,
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
" rmaps_base_n_persocket, rmaps_ppr_n_persocket " ,
2014-02-26 18:12:23 +00:00
" rmaps_base_mapping_policy=ppr:N:socket " ) ;
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
/* there is no way to resolve this conflict, so if something else was
* given , we have no choice but to error out
*/
if ( ORTE_MAPPING_GIVEN & ORTE_GET_MAPPING_DIRECTIVE ( orte_rmaps_base . mapping ) ) {
orte_show_help ( " help-orte-rmaps-base.txt " , " redefining-policy " , true , " mapping " ,
" bynode " , orte_rmaps_base_print_mapping ( orte_rmaps_base . mapping ) ) ;
return ORTE_ERR_SILENT ;
}
/* ensure we set the mapping policy to ppr */
ORTE_SET_MAPPING_POLICY ( orte_rmaps_base . mapping , ORTE_MAPPING_PPR ) ;
ORTE_SET_MAPPING_DIRECTIVE ( orte_rmaps_base . mapping , ORTE_MAPPING_GIVEN ) ;
/* define the ppr */
asprintf ( & orte_rmaps_base . ppr , " %d:socket " , orte_rmaps_base_n_persocket ) ;
}
2006-07-04 20:12:35 +00:00
/* Should we schedule on the local node or not? */
2013-03-27 21:09:41 +00:00
if ( rmaps_base_no_schedule_local ) {
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
orte_rmaps_base . mapping | = ORTE_MAPPING_NO_USE_LOCAL ;
2008-04-09 22:10:53 +00:00
}
2006-07-04 20:12:35 +00:00
2006-07-10 14:10:21 +00:00
/* Should we oversubscribe or not? */
2013-03-27 21:09:41 +00:00
if ( rmaps_base_no_oversubscribe ) {
At long last, the fabled revision to the affinity system has arrived. A more detailed explanation of how this all works will be presented here:
https://svn.open-mpi.org/trac/ompi/wiki/ProcessPlacement
The wiki page is incomplete at the moment, but I hope to complete it over the next few days. I will provide updates on the devel list. As the wiki page states, the default and most commonly used options remain unchanged (except as noted below). New, esoteric and complex options have been added, but unless you are a true masochist, you are unlikely to use many of them beyond perhaps an initial curiosity-motivated experimentation.
In a nutshell, this commit revamps the map/rank/bind procedure to take into account topology info on the compute nodes. I have, for the most part, preserved the default behaviors, with three notable exceptions:
1. I have at long last bowed my head in submission to the system admin's of managed clusters. For years, they have complained about our default of allowing users to oversubscribe nodes - i.e., to run more processes on a node than allocated slots. Accordingly, I have modified the default behavior: if you are running off of hostfile/dash-host allocated nodes, then the default is to allow oversubscription. If you are running off of RM-allocated nodes, then the default is to NOT allow oversubscription. Flags to override these behaviors are provided, so this only affects the default behavior.
2. both cpus/rank and stride have been removed. The latter was demanded by those who didn't understand the purpose behind it - and I agreed as the users who requested it are no longer using it. The former was removed temporarily pending implementation.
3. vm launch is now the sole method for starting OMPI. It was just too darned hard to maintain multiple launch procedures - maybe someday, provided someone can demonstrate a reason to do so.
As Jeff stated, it is impossible to fully test a change of this size. I have tested it on Linux and Mac, covering all the default and simple options, singletons, and comm_spawn. That said, I'm sure others will find problems, so I'll be watching MTT results until this stabilizes.
This commit was SVN r25476.
2011-11-15 03:40:11 +00:00
if ( ( ORTE_MAPPING_SUBSCRIBE_GIVEN & ORTE_GET_MAPPING_DIRECTIVE ( orte_rmaps_base . mapping ) ) & &
! ( ORTE_MAPPING_NO_OVERSUBSCRIBE & ORTE_GET_MAPPING_DIRECTIVE ( orte_rmaps_base . mapping ) ) ) {
/* error - cannot redefine the default mapping policy */
orte_show_help ( " help-orte-rmaps-base.txt " , " redefining-policy " , true , " mapping " ,
" no-oversubscribe " , orte_rmaps_base_print_mapping ( orte_rmaps_base . mapping ) ) ;
return ORTE_ERR_SILENT ;
}
ORTE_SET_MAPPING_DIRECTIVE ( orte_rmaps_base . mapping , ORTE_MAPPING_NO_OVERSUBSCRIBE ) ;
ORTE_SET_MAPPING_DIRECTIVE ( orte_rmaps_base . mapping , ORTE_MAPPING_SUBSCRIBE_GIVEN ) ;
2006-07-10 14:10: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
/** force oversubscription permission */
2013-03-27 21:09:41 +00:00
if ( rmaps_base_oversubscribe ) {
At long last, the fabled revision to the affinity system has arrived. A more detailed explanation of how this all works will be presented here:
https://svn.open-mpi.org/trac/ompi/wiki/ProcessPlacement
The wiki page is incomplete at the moment, but I hope to complete it over the next few days. I will provide updates on the devel list. As the wiki page states, the default and most commonly used options remain unchanged (except as noted below). New, esoteric and complex options have been added, but unless you are a true masochist, you are unlikely to use many of them beyond perhaps an initial curiosity-motivated experimentation.
In a nutshell, this commit revamps the map/rank/bind procedure to take into account topology info on the compute nodes. I have, for the most part, preserved the default behaviors, with three notable exceptions:
1. I have at long last bowed my head in submission to the system admin's of managed clusters. For years, they have complained about our default of allowing users to oversubscribe nodes - i.e., to run more processes on a node than allocated slots. Accordingly, I have modified the default behavior: if you are running off of hostfile/dash-host allocated nodes, then the default is to allow oversubscription. If you are running off of RM-allocated nodes, then the default is to NOT allow oversubscription. Flags to override these behaviors are provided, so this only affects the default behavior.
2. both cpus/rank and stride have been removed. The latter was demanded by those who didn't understand the purpose behind it - and I agreed as the users who requested it are no longer using it. The former was removed temporarily pending implementation.
3. vm launch is now the sole method for starting OMPI. It was just too darned hard to maintain multiple launch procedures - maybe someday, provided someone can demonstrate a reason to do so.
As Jeff stated, it is impossible to fully test a change of this size. I have tested it on Linux and Mac, covering all the default and simple options, singletons, and comm_spawn. That said, I'm sure others will find problems, so I'll be watching MTT results until this stabilizes.
This commit was SVN r25476.
2011-11-15 03:40:11 +00:00
if ( ( ORTE_MAPPING_SUBSCRIBE_GIVEN & ORTE_GET_MAPPING_DIRECTIVE ( orte_rmaps_base . mapping ) ) & &
( ORTE_MAPPING_NO_OVERSUBSCRIBE & ORTE_GET_MAPPING_DIRECTIVE ( orte_rmaps_base . mapping ) ) ) {
/* error - cannot redefine the default mapping policy */
orte_show_help ( " help-orte-rmaps-base.txt " , " redefining-policy " , true , " mapping " ,
" oversubscribe " , orte_rmaps_base_print_mapping ( orte_rmaps_base . mapping ) ) ;
return ORTE_ERR_SILENT ;
}
ORTE_UNSET_MAPPING_DIRECTIVE ( orte_rmaps_base . mapping , ORTE_MAPPING_NO_OVERSUBSCRIBE ) ;
ORTE_SET_MAPPING_DIRECTIVE ( orte_rmaps_base . mapping , ORTE_MAPPING_SUBSCRIBE_GIVEN ) ;
2014-06-25 18:13:54 +00:00
# if OPAL_HAVE_HWLOC
2014-06-24 18:11:39 +00:00
/* also set the overload allowed flag */
opal_hwloc_binding_policy | = OPAL_BIND_ALLOW_OVERLOAD ;
2014-06-25 18:13:54 +00:00
# endif
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
}
2008-09-23 15:46:34 +00:00
/* should we display a detailed (developer-quality) version of the map after determining it? */
2013-03-27 21:09:41 +00:00
if ( rmaps_base_display_devel_map ) {
2008-09-23 15:46:34 +00:00
orte_rmaps_base . display_map = true ;
orte_devel_level_output = true ;
}
2011-10-29 15:12:45 +00:00
2011-11-03 14:22:07 +00:00
/* should we display a diffable report of proc locations after determining it? */
2013-03-27 21:09:41 +00:00
if ( rmaps_base_display_diffable_map ) {
2011-11-03 14:22:07 +00:00
orte_rmaps_base . display_map = true ;
orte_display_diffable_output = true ;
}
2013-03-27 21:14:43 +00:00
/* Open up all available components */
rc = mca_base_framework_components_open ( & orte_rmaps_base_framework , flags ) ;
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
/* check to see if any component indicated a problem */
if ( ORTE_MAPPING_CONFLICTED & ORTE_GET_MAPPING_DIRECTIVE ( orte_rmaps_base . mapping ) ) {
/* the component would have already reported the error, so
* tell the rest of the chain to shut up
*/
return ORTE_ERR_SILENT ;
}
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
/* All done */
2013-03-27 21:14:43 +00:00
return rc ;
2005-03-14 20:57:21 +00:00
}
2008-06-18 03:15:56 +00:00
2013-03-27 21:14:43 +00:00
MCA_BASE_FRAMEWORK_DECLARE ( orte , rmaps , " ORTE Mapping Subsystem " ,
orte_rmaps_base_register , orte_rmaps_base_open , orte_rmaps_base_close ,
mca_rmaps_base_static_components , 0 ) ;
2011-02-15 23:24:31 +00:00
OBJ_CLASS_INSTANCE ( orte_rmaps_base_selected_module_t ,
opal_list_item_t ,
NULL , NULL ) ;
2013-12-20 20:42:39 +00:00
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
static int check_modifiers ( char * ck , orte_mapping_policy_t * tmp )
{
char * * ck2 , * ptr ;
int i ;
bool found = false ;
2014-06-13 20:10:09 +00:00
opal_output_verbose ( 5 , orte_rmaps_base_framework . framework_output ,
" %s rmaps:base check modifiers with %s " ,
ORTE_NAME_PRINT ( ORTE_PROC_MY_NAME ) ,
( NULL = = ck ) ? " NULL " : ck ) ;
2014-02-11 17:34:37 +00:00
if ( NULL = = ck ) {
return ORTE_SUCCESS ;
}
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
ck2 = opal_argv_split ( ck , ' , ' ) ;
for ( i = 0 ; NULL ! = ck2 [ i ] ; i + + ) {
if ( 0 = = strncasecmp ( ck2 [ i ] , " span " , strlen ( ck2 [ i ] ) ) ) {
ORTE_SET_MAPPING_DIRECTIVE ( * tmp , ORTE_MAPPING_SPAN ) ;
found = true ;
} else if ( 0 = = strncasecmp ( ck2 [ i ] , " pe " , strlen ( " pe " ) ) ) {
/* break this at the = sign to get the number */
if ( NULL = = ( ptr = strchr ( ck2 [ i ] , ' = ' ) ) ) {
/* missing the value */
orte_show_help ( " help-orte-rmaps-base.txt " , " missing-value " , true , " pe " , ck2 [ i ] ) ;
return ORTE_ERR_SILENT ;
}
ptr + + ;
if ( NULL = = ptr ) {
/* still missing the value */
return ORTE_ERR_SILENT ;
}
orte_rmaps_base . cpus_per_rank = strtol ( ptr , NULL , 10 ) ;
2014-06-08 20:26:59 +00:00
opal_output_verbose ( 5 , orte_rmaps_base_framework . framework_output ,
" %s rmaps:base setting pe/rank to %d " ,
ORTE_NAME_PRINT ( ORTE_PROC_MY_NAME ) ,
orte_rmaps_base . cpus_per_rank ) ;
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
found = true ;
} else if ( 0 = = strncasecmp ( ck2 [ i ] , " oversubscribe " , strlen ( ck2 [ i ] ) ) ) {
ORTE_UNSET_MAPPING_DIRECTIVE ( * tmp , ORTE_MAPPING_NO_OVERSUBSCRIBE ) ;
ORTE_SET_MAPPING_DIRECTIVE ( * tmp , ORTE_MAPPING_SUBSCRIBE_GIVEN ) ;
found = true ;
} else if ( 0 = = strncasecmp ( ck2 [ i ] , " nooversubscribe " , strlen ( ck2 [ i ] ) ) ) {
ORTE_SET_MAPPING_DIRECTIVE ( * tmp , ORTE_MAPPING_NO_OVERSUBSCRIBE ) ;
ORTE_SET_MAPPING_DIRECTIVE ( * tmp , ORTE_MAPPING_SUBSCRIBE_GIVEN ) ;
found = true ;
} else {
/* unrecognized modifier */
opal_argv_free ( ck2 ) ;
2014-06-13 20:10:09 +00:00
return ORTE_ERR_BAD_PARAM ;
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
}
}
opal_argv_free ( ck2 ) ;
if ( found ) {
return ORTE_SUCCESS ;
}
return ORTE_ERR_TAKE_NEXT_OPTION ;
}
2013-12-20 20:42:39 +00:00
int orte_rmaps_base_set_mapping_policy ( orte_mapping_policy_t * policy ,
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
char * * device , char * inspec )
2013-12-20 20:42:39 +00:00
{
2014-03-05 02:48:15 +00:00
char * ck ;
# if OPAL_HAVE_HWLOC
char * ptr ;
# endif
2013-12-20 20:42:39 +00:00
orte_mapping_policy_t tmp ;
2014-02-11 17:19:05 +00:00
int rc ;
2013-12-20 20:42:39 +00:00
size_t len ;
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
char * spec ;
2013-12-20 20:42:39 +00:00
/* set defaults */
tmp = 0 ;
* device = NULL ;
2014-06-08 20:26:59 +00:00
opal_output_verbose ( 5 , orte_rmaps_base_framework . framework_output ,
" %s rmaps:base set policy with %s " ,
ORTE_NAME_PRINT ( ORTE_PROC_MY_NAME ) ,
( NULL = = inspec ) ? " NULL " : inspec ) ;
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
if ( NULL = = inspec ) {
2013-12-20 20:42:39 +00:00
ORTE_SET_MAPPING_POLICY ( tmp , ORTE_MAPPING_BYSOCKET ) ;
} else {
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
spec = strdup ( inspec ) ; // protect the input string
/* see if a colon was included - if so, then we have a policy + modifier */
ck = strchr ( spec , ' : ' ) ;
if ( NULL ! = ck ) {
2014-06-08 20:26:59 +00:00
/* if the colon is the first character of the string, then we
* just have modifiers on the default mapping policy */
if ( ck = = spec ) {
ck + + ;
opal_output_verbose ( 5 , orte_rmaps_base_framework . framework_output ,
" %s rmaps:base only modifiers %s provided - assuming bysocket mapping " ,
ORTE_NAME_PRINT ( ORTE_PROC_MY_NAME ) , ck ) ;
ORTE_SET_MAPPING_POLICY ( tmp , ORTE_MAPPING_BYSOCKET ) ;
if ( ORTE_ERR_SILENT = = ( rc = check_modifiers ( ck , & tmp ) ) & &
ORTE_ERR_BAD_PARAM ! = rc ) {
free ( spec ) ;
return ORTE_ERR_SILENT ;
}
free ( spec ) ;
goto setpolicy ;
}
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
/* split the string */
* ck = ' \0 ' ;
ck + + ;
2014-06-08 20:26:59 +00:00
opal_output_verbose ( 5 , orte_rmaps_base_framework . framework_output ,
" %s rmaps:base policy %s modifiers %s provided " ,
ORTE_NAME_PRINT ( ORTE_PROC_MY_NAME ) , spec , ck ) ;
2013-12-20 20:42:39 +00:00
/* if the policy is "dist", then we set the policy to that value
* and save the second argument as the device
*/
# if OPAL_HAVE_HWLOC
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
if ( 0 = = strncasecmp ( spec , " dist " , strlen ( spec ) ) ) {
2013-12-20 20:42:39 +00:00
ORTE_SET_MAPPING_POLICY ( tmp , ORTE_MAPPING_BYDIST ) ;
2014-02-11 17:19:05 +00:00
/* the first argument after the colon *must* be the
* device we are mapping near - however , other modifiers
* could have been provided , so check for them , okay if
* none found
*/
if ( NULL ! = ( ptr = strchr ( ck , ' , ' ) ) ) {
* ptr = ' \0 ' ;
ptr + + ; // move past the comma
/* check the remaining string for modifiers - may be none, so
* don ' t emit an error message if the modifier isn ' t recognized
*/
if ( ORTE_ERR_SILENT = = ( rc = check_modifiers ( ptr , & tmp ) ) & &
ORTE_ERR_BAD_PARAM ! = rc ) {
free ( spec ) ;
return ORTE_ERR_SILENT ;
2013-12-20 20:42:39 +00:00
}
}
2014-02-11 17:19:05 +00:00
* device = strdup ( ck ) ;
2014-01-04 20:44:41 +00:00
ORTE_SET_MAPPING_DIRECTIVE ( tmp , ORTE_MAPPING_GIVEN ) ;
2014-02-11 17:19:05 +00:00
free ( spec ) ;
2013-12-20 20:42:39 +00:00
goto setpolicy ;
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
} else if ( 0 = = strncasecmp ( spec , " ppr " , strlen ( spec ) ) ) {
/* we have to allow additional modifiers here - e.g., specifying
* # pe ' s / proc or oversubscribe - so check for modifiers
*/
if ( NULL = = ( ptr = strrchr ( ck , ' : ' ) ) ) {
/* this is an error - there had to be at least one
* colon to delimit the number from the object type
*/
orte_show_help ( " help-orte-rmaps-base.txt " , " invalid-pattern " , true , inspec ) ;
2014-02-11 17:19:05 +00:00
free ( spec ) ;
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
return ORTE_ERR_SILENT ;
}
ptr + + ; // move past the colon
/* check the remaining string for modifiers - may be none, so
* don ' t emit an error message if the modifier isn ' t recognized
*/
if ( ORTE_ERR_SILENT = = ( rc = check_modifiers ( ptr , & tmp ) ) & &
ORTE_ERR_BAD_PARAM ! = rc ) {
2014-02-11 17:19:05 +00:00
free ( spec ) ;
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
return ORTE_ERR_SILENT ;
}
/* if we found something, then we need to adjust the string */
if ( ORTE_SUCCESS = = rc ) {
ptr - - ;
* ptr = ' \0 ' ;
}
/* now get the pattern */
orte_rmaps_base . ppr = strdup ( ck ) ;
ORTE_SET_MAPPING_POLICY ( tmp , ORTE_MAPPING_PPR ) ;
ORTE_SET_MAPPING_DIRECTIVE ( tmp , ORTE_MAPPING_GIVEN ) ;
2014-02-11 17:19:05 +00:00
free ( spec ) ;
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
goto setpolicy ;
2013-12-20 20:42:39 +00:00
}
# endif
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
if ( ORTE_SUCCESS ! = ( rc = check_modifiers ( ck , & tmp ) ) & &
ORTE_ERR_TAKE_NEXT_OPTION ! = rc ) {
if ( ORTE_ERR_BAD_PARAM = = rc ) {
orte_show_help ( " help-orte-rmaps-base.txt " , " unrecognized-modifier " , true , inspec ) ;
2013-12-20 20:42:39 +00:00
}
2014-02-11 17:19:05 +00:00
free ( spec ) ;
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
return rc ;
2013-12-20 20:42:39 +00:00
}
}
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
len = strlen ( spec ) ;
if ( 0 = = strncasecmp ( spec , " slot " , len ) ) {
2013-12-20 20:42:39 +00:00
ORTE_SET_MAPPING_POLICY ( tmp , ORTE_MAPPING_BYSLOT ) ;
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
} else if ( 0 = = strncasecmp ( spec , " node " , len ) ) {
2013-12-20 20:42:39 +00:00
ORTE_SET_MAPPING_POLICY ( tmp , ORTE_MAPPING_BYNODE ) ;
2014-04-08 03:38:25 +00:00
} else if ( 0 = = strncasecmp ( spec , " seq " , len ) ) {
ORTE_SET_MAPPING_POLICY ( tmp , ORTE_MAPPING_SEQ ) ;
2013-12-20 20:42:39 +00:00
# if OPAL_HAVE_HWLOC
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
} else if ( 0 = = strncasecmp ( spec , " core " , len ) ) {
2013-12-20 20:42:39 +00:00
ORTE_SET_MAPPING_POLICY ( tmp , ORTE_MAPPING_BYCORE ) ;
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
} else if ( 0 = = strncasecmp ( spec , " l1cache " , len ) ) {
2013-12-20 20:42:39 +00:00
ORTE_SET_MAPPING_POLICY ( tmp , ORTE_MAPPING_BYL1CACHE ) ;
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
} else if ( 0 = = strncasecmp ( spec , " l2cache " , len ) ) {
2013-12-20 20:42:39 +00:00
ORTE_SET_MAPPING_POLICY ( tmp , ORTE_MAPPING_BYL2CACHE ) ;
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
} else if ( 0 = = strncasecmp ( spec , " l3cache " , len ) ) {
2013-12-20 20:42:39 +00:00
ORTE_SET_MAPPING_POLICY ( tmp , ORTE_MAPPING_BYL3CACHE ) ;
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
} else if ( 0 = = strncasecmp ( spec , " socket " , len ) ) {
2013-12-20 20:42:39 +00:00
ORTE_SET_MAPPING_POLICY ( tmp , ORTE_MAPPING_BYSOCKET ) ;
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
} else if ( 0 = = strncasecmp ( spec , " numa " , len ) ) {
2013-12-20 20:42:39 +00:00
ORTE_SET_MAPPING_POLICY ( tmp , ORTE_MAPPING_BYNUMA ) ;
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
} else if ( 0 = = strncasecmp ( spec , " board " , len ) ) {
2013-12-20 20:42:39 +00:00
ORTE_SET_MAPPING_POLICY ( tmp , ORTE_MAPPING_BYBOARD ) ;
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
} else if ( 0 = = strncasecmp ( spec , " hwthread " , len ) ) {
2013-12-20 20:42:39 +00:00
ORTE_SET_MAPPING_POLICY ( tmp , ORTE_MAPPING_BYHWTHREAD ) ;
/* if we are mapping processes to individual hwthreads, then
* we need to treat those hwthreads as separate cpus
*/
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
opal_hwloc_use_hwthreads_as_cpus = true ;
2013-12-20 20:42:39 +00:00
# endif
} else {
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
orte_show_help ( " help-orte-rmaps-base.txt " , " unrecognized-policy " , true , " mapping " , spec ) ;
free ( spec ) ;
2013-12-20 20:42:39 +00:00
return ORTE_ERR_SILENT ;
}
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
free ( spec ) ;
2013-12-20 20:42:39 +00:00
ORTE_SET_MAPPING_DIRECTIVE ( tmp , ORTE_MAPPING_GIVEN ) ;
}
setpolicy :
* policy = tmp ;
return ORTE_SUCCESS ;
}
int orte_rmaps_base_set_ranking_policy ( orte_ranking_policy_t * policy ,
orte_mapping_policy_t mapping ,
char * spec )
{
2014-02-14 10:23:16 +00:00
orte_mapping_policy_t map ;
2013-12-20 20:42:39 +00:00
orte_ranking_policy_t tmp ;
char * * ck ;
size_t len ;
/* set default */
tmp = 0 ;
if ( NULL = = spec ) {
/* check for map-by object directives - we set the
* ranking to match if one was given
*/
if ( ORTE_MAPPING_GIVEN & ORTE_GET_MAPPING_DIRECTIVE ( mapping ) ) {
2014-02-14 10:23:16 +00:00
map = ORTE_GET_MAPPING_POLICY ( mapping ) ;
switch ( map ) {
case ORTE_MAPPING_BYSLOT :
ORTE_SET_RANKING_POLICY ( tmp , ORTE_RANK_BY_SLOT ) ;
break ;
case ORTE_MAPPING_BYNODE :
2013-12-20 20:42:39 +00:00
ORTE_SET_RANKING_POLICY ( tmp , ORTE_RANK_BY_NODE ) ;
2014-02-14 10:23:16 +00:00
break ;
# if OPAL_HAVE_HWLOC
case ORTE_MAPPING_BYCORE :
ORTE_SET_RANKING_POLICY ( tmp , ORTE_RANK_BY_CORE ) ;
break ;
case ORTE_MAPPING_BYL1CACHE :
2013-12-20 20:42:39 +00:00
ORTE_SET_RANKING_POLICY ( tmp , ORTE_RANK_BY_L1CACHE ) ;
2014-02-14 10:23:16 +00:00
break ;
case ORTE_MAPPING_BYL2CACHE :
2013-12-20 20:42:39 +00:00
ORTE_SET_RANKING_POLICY ( tmp , ORTE_RANK_BY_L2CACHE ) ;
2014-02-14 10:23:16 +00:00
break ;
case ORTE_MAPPING_BYL3CACHE :
2013-12-20 20:42:39 +00:00
ORTE_SET_RANKING_POLICY ( tmp , ORTE_RANK_BY_L3CACHE ) ;
2014-02-14 10:23:16 +00:00
break ;
case ORTE_MAPPING_BYSOCKET :
2013-12-20 20:42:39 +00:00
ORTE_SET_RANKING_POLICY ( tmp , ORTE_RANK_BY_SOCKET ) ;
2014-02-14 10:23:16 +00:00
break ;
case ORTE_MAPPING_BYNUMA :
2013-12-20 20:42:39 +00:00
ORTE_SET_RANKING_POLICY ( tmp , ORTE_RANK_BY_NUMA ) ;
2014-02-14 10:23:16 +00:00
break ;
case ORTE_MAPPING_BYBOARD :
2013-12-20 20:42:39 +00:00
ORTE_SET_RANKING_POLICY ( tmp , ORTE_RANK_BY_BOARD ) ;
2014-02-14 10:23:16 +00:00
break ;
case ORTE_MAPPING_BYHWTHREAD :
2013-12-20 20:42:39 +00:00
ORTE_SET_RANKING_POLICY ( tmp , ORTE_RANK_BY_HWTHREAD ) ;
2014-02-14 10:23:16 +00:00
break ;
# endif
default :
/* anything not tied to a specific hw obj can rank by slot */
ORTE_SET_RANKING_POLICY ( tmp , ORTE_RANK_BY_SLOT ) ;
break ;
2013-12-20 20:42:39 +00:00
}
} else {
/* if no map-by was given, default to by-slot */
ORTE_SET_RANKING_POLICY ( tmp , ORTE_RANK_BY_SLOT ) ;
}
} else {
ck = opal_argv_split ( spec , ' : ' ) ;
if ( 2 < opal_argv_count ( ck ) ) {
/* incorrect format */
orte_show_help ( " help-orte-rmaps-base.txt " , " unrecognized-policy " , true , " ranking " , policy ) ;
opal_argv_free ( ck ) ;
return ORTE_ERR_SILENT ;
}
if ( 2 = = opal_argv_count ( ck ) ) {
if ( 0 = = strncasecmp ( ck [ 1 ] , " span " , strlen ( ck [ 1 ] ) ) ) {
ORTE_SET_RANKING_DIRECTIVE ( tmp , ORTE_RANKING_SPAN ) ;
} else if ( 0 = = strncasecmp ( ck [ 1 ] , " fill " , strlen ( ck [ 1 ] ) ) ) {
ORTE_SET_RANKING_DIRECTIVE ( tmp , ORTE_RANKING_FILL ) ;
} else {
/* unrecognized modifier */
2014-08-11 03:22:05 +00:00
orte_show_help ( " help-orte-rmaps-base.txt " , " unrecognized-modifier " , true , ck [ 1 ] ) ;
2013-12-20 20:42:39 +00:00
opal_argv_free ( ck ) ;
return ORTE_ERR_SILENT ;
}
}
len = strlen ( ck [ 0 ] ) ;
if ( 0 = = strncasecmp ( ck [ 0 ] , " slot " , len ) ) {
ORTE_SET_RANKING_POLICY ( tmp , ORTE_RANK_BY_SLOT ) ;
} else if ( 0 = = strncasecmp ( ck [ 0 ] , " node " , len ) ) {
ORTE_SET_RANKING_POLICY ( tmp , ORTE_RANK_BY_NODE ) ;
# if OPAL_HAVE_HWLOC
} else if ( 0 = = strncasecmp ( ck [ 0 ] , " hwthread " , len ) ) {
ORTE_SET_RANKING_POLICY ( tmp , ORTE_RANK_BY_HWTHREAD ) ;
} else if ( 0 = = strncasecmp ( ck [ 0 ] , " core " , len ) ) {
ORTE_SET_RANKING_POLICY ( tmp , ORTE_RANK_BY_CORE ) ;
} else if ( 0 = = strncasecmp ( ck [ 0 ] , " l1cache " , len ) ) {
ORTE_SET_RANKING_POLICY ( tmp , ORTE_RANK_BY_L1CACHE ) ;
} else if ( 0 = = strncasecmp ( ck [ 0 ] , " l2cache " , len ) ) {
ORTE_SET_RANKING_POLICY ( tmp , ORTE_RANK_BY_L2CACHE ) ;
} else if ( 0 = = strncasecmp ( ck [ 0 ] , " l3cache " , len ) ) {
ORTE_SET_RANKING_POLICY ( tmp , ORTE_RANK_BY_L3CACHE ) ;
} else if ( 0 = = strncasecmp ( ck [ 0 ] , " socket " , len ) ) {
ORTE_SET_RANKING_POLICY ( tmp , ORTE_RANK_BY_SOCKET ) ;
} else if ( 0 = = strncasecmp ( ck [ 0 ] , " numa " , len ) ) {
ORTE_SET_RANKING_POLICY ( tmp , ORTE_RANK_BY_NUMA ) ;
} else if ( 0 = = strncasecmp ( ck [ 0 ] , " board " , len ) ) {
ORTE_SET_RANKING_POLICY ( tmp , ORTE_RANK_BY_BOARD ) ;
# endif
} else {
orte_show_help ( " help-orte-rmaps-base.txt " , " unrecognized-policy " , true , " ranking " , rmaps_base_ranking_policy ) ;
return ORTE_ERR_SILENT ;
}
opal_argv_free ( ck ) ;
ORTE_SET_RANKING_DIRECTIVE ( tmp , ORTE_RANKING_GIVEN ) ;
}
* policy = tmp ;
return ORTE_SUCCESS ;
}
