bgirgis/cpp-thirdparty
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Upgrade MPIs on linux

Browse Source
This commit is contained in:
Bassem Girgis
2025-03-19 12:53:34 -05:00
parent d29ef955f5
commit a6198ecc7b
5503 changed files with 962014 additions and 56494 deletions
Download Patch File Download Diff File Expand all files Collapse all files

83
linx64/mpi/openmpi/share/man/man7/Open-MPI.7 Normal file
View File

@@ -0,0 +1,83 @@
.\" Man page generated from reStructuredText.
.
.TH "OPEN-MPI" "7" "Feb 14, 2025" "" "Open MPI"
.
.nr rst2man-indent-level 0
.
.de1 rstReportMargin
\\$1 \\n[an-margin]
level \\n[rst2man-indent-level]
level margin: \\n[rst2man-indent\\n[rst2man-indent-level]]
-
\\n[rst2man-indent0]
\\n[rst2man-indent1]
\\n[rst2man-indent2]
..
.de1 INDENT
.\" .rstReportMargin pre:
. RS \\$1
. nr rst2man-indent\\n[rst2man-indent-level] \\n[an-margin]
. nr rst2man-indent-level +1
.\" .rstReportMargin post:
..
.de UNINDENT
. RE
.\" indent \\n[an-margin]
.\" old: \\n[rst2man-indent\\n[rst2man-indent-level]]
.nr rst2man-indent-level -1
.\" new: \\n[rst2man-indent\\n[rst2man-indent-level]]
.in \\n[rst2man-indent\\n[rst2man-indent-level]]u
..
.sp
Open MPI \- General information
.SH OPEN MPI
.sp
Open MPI is an open source implementation of MPI (message\-passing
interface), the industry\-standard specification for writing
message\-passing programs. Message passing is a programming model that
gives the programmer explicit control over interprocess communication.
.sp
The MPI specification was developed by the MPI Forum, a group of
software developers, computer vendors, academics, and computer\-science
researchers whose goal was to develop a standard for writing
message\-passing programs that would be efficient, flexible, and
portable.
.sp
The outcome, known as the MPI Standard, was first published in 1993; its
most recent version (MPI\-4.0) was published in June 2021. Open MPI
includes all MPI 3.1\-compliant routines.
.sp
For more information about Open MPI, see \fI\%https://www.open\-mpi.org\fP\&.
.sp
The MPI standards are available at \fI\%https://www.mpi\-forum.org\fP\&.
.SH MAN PAGE SYNTAX
.sp
Man pages for Open MPI and Open MPI I/O routines are named according to
C syntax, that is, they begin with the prefix \fBMPI_\fP, all in
uppercase, and the first letter following the \fBMPI_\fP prefix is also
uppercase. The rest of the letters in the routine are all lowercase, for
example, \fI\%MPI_Comm_get_attr\fP\&.
.SH ENVIRONMENT
.sp
To fine\-tune your Open MPI environment, you can either use arguments
to the \fI\%mpirun\fP or \fI\%mpiexec\fP
commands, or you can use MCA parameters.
.sp
For more information on arguments, see the \fI\%mpirun(1)\fP man page.
.sp
For a complete listing of MCA parameters and their descriptions, issue
the command \fBompi_info \-\-all\fP\&. See \fI\%ompi_info(1)\fP for more information.
.SH ERRORS
.sp
See \fI\%MPI Errors\fP for details about error values.
.sp
\fBSEE ALSO:\fP
.INDENT 0.0
.INDENT 3.5
\fI\%MPI_T\fP \fI\%mpirun(1)\fP \fI\%mpiexec(1)\fP \fI\%ompi_info(1)\fP
.UNINDENT
.UNINDENT
.SH COPYRIGHT
2003-2025, The Open MPI Community
.\" Generated by docutils manpage writer.
.

359
linx64/mpi/openmpi/share/man/man7/hwloc.7 Normal file
View File

@@ -0,0 +1,359 @@
.\" -*- nroff -*-
.\" Copyright © 2010-2020 Inria. All rights reserved.
.\" Copyright © 2010 Université of Bordeaux
.\" Copyright © 2009-2010 Cisco Systems, Inc. All rights reserved.
.\" See COPYING in top-level directory.
.TH HWLOC "7" "Mar 20, 2022" "2.7.1" "hwloc"
.SH NAME
hwloc - General information about hwloc ("hardware locality").
.
.\" **************************
.\" Description Section
.\" **************************
.SH DESCRIPTION
.
hwloc provides command line tools and a C API to obtain the
hierarchical map of key computing elements, such as: NUMA memory
nodes, shared caches, processor packages, processor cores, and
processor "threads". hwloc also gathers various attributes such as
cache and memory information, and is portable across a variety of
different operating systems and platforms.
.
.
.SS Definitions
hwloc has some specific definitions for terms that are used in this
man page and other hwloc documentation.
.
.TP 5
.B hwloc CPU set:
A set of processors included in an hwloc object, expressed as a bitmask
indexed by the physical numbers of the CPUs (as announced by the OS).
The hwloc definition
of "CPU set" does not carry any of the same connotations as Linux's "CPU
set" (e.g., process affinity, cgroup, etc.).
.
.TP
.B hwloc node set:
A set of NUMA memory nodes near an hwloc object, expressed as a bitmask
indexed by the physical numbers of the NUMA nodes (as announced by the OS).
.
.TP
.B Linux CPU set:
See http://www.mjmwired.net/kernel/Documentation/cpusets.txt for a
discussion of Linux CPU sets. A
super-short-ignoring-many-details description (taken from that page)
is:
.br
.br
"Cpusets provide a mechanism for assigning a set of CPUs and Memory
Nodes to a set of tasks."
.
.TP
.B Linux Cgroup:
See http://www.mjmwired.net/kernel/Documentation/cgroups.txt for a
discussion of Linux control groups. A
super-short-ignoring-many-details description (taken from that page)
is:
.br
.br
"Control Groups provide a mechanism for aggregating/partitioning sets
of tasks, and all their future children, into hierarchical groups
with specialized behaviour."
.
.PP
To be clear, hwloc supports all of the above concepts. It is simply
worth noting that they are different things.
.
.SS Location Specification
.
Locations refer to specific regions within a topology. Before reading
the rest of this man page, it may be useful to read lstopo(1) and/or
run lstopo on your machine to see the reported topology tree. Seeing
and understanding a topology tree will definitely help in
understanding the concepts that are discussed below.
.
.PP
Locations can be specified in multiple ways:
.
.TP 10
.B Tuples:
Tuples of hwloc "objects" and associated indexes can be specified in
the form
.IR object:index .
hwloc objects represent types of mapped items (e.g., packages, cores,
etc.) in a topology tree; indexes are non-negative integers that
specify a unique physical object in a topology tree. Both concepts
are described in detail, below.
.br
.br
Indexes may also be specified as ranges.
\fIx-y\fR enumerates from index \fIx\fR to \fIy\fR.
\fIx:y\fR enumerates \fIy\fR objects starting from index \fIx\fR
(wrapping around the end of the index range if needed).
\fIx-\fR enumerates all objects starting from index \fIx\fR.
\fIall\fR, \fIodd\fR, and \fIeven\fR are also supported for listing
all objects, or only those with odd or even indexes.
.br
.br
Chaining multiple tuples together in the more general form
.I object1:index[.object2:index2[...]]
is permissable. While the first tuple's object may appear anywhere in
the topology, the Nth tuple's object must have a shallower topology
depth than the (N+1)th tuple's object. Put simply: as you move right
in a tuple chain, objects must go deeper in the topology tree.
When using logical indexes (which is the default),
indexes specified in chained tuples are relative to the scope of the
parent object. For example, "package:0.core:1" refers to the second
core in the first package.
.br
.br
When using OS/physical indexes, the first object matching the given
index is used.
.br
.br
PCI and OS devices may also be designed using their identifier.
For example, "\fBpci=02:03.1\fR" is the PCI device with bus ID "02:03.1".
.
"\fBos=eth0\fR" is the network interface whose software name is "eth0".
.
PCI devices may also be filtered based on their vendor and/or device IDs,
for instance "\fBpci[15b3:]:2\fR" for the third Mellanox PCI device (vendor ID 0x15b3).
.
OS devices may also be filtered based on their subtype,
for instance "\fBos[gpu]:all\fR" for all GPU OS devices.
.
.TP
.B Hex:
For tools that manipulate object as sets (e.g. hwloc-calc and hwloc-bind),
locations can also be specified as hexidecimal bitmasks prefixed
.
with "0x". Commas must be used to separate the hex digits into blocks
of 8, such as "0xffc0140,0x00020110".
.
Leading zeros in each block do not need to be specified.
.
For example, "0xffc0140,0x20110" is equivalent to the prior example,
and "0x0000000f" is exactly equivalent to "0xf". Intermediate blocks
of 8 digits that are all zeoro can be left empty; "0xff0,,0x13" is
equivalent to "0xff0,0x00000000,0x13".
.
If the location is prefixed with the special string "0xf...f", then
all unspecified bits are set (as if the set were infinite). For
example, "0xf...f,0x1" sets both the first bit and all bits starting
with the 33rd. The string "0xf...f" -- with no other specified values
-- sets all bits.
.
.PP
"all" and "root" are special locations consisting in the root
object in tree. It contains the entire current topology.
.
.PP
Some tools directly operate on these objects (e.g. hwloc-info and hwloc-annotate).
They do not support hexadecimal locations because each location may
correspond to multiple objects.
For instance, there can be exactly one L3 cache per package and NUMA node,
which means it's the same location.
.
If multiple locations are given on the command-line,
these tools will operation on each location individually and consecutively.
.
.PP
Some other tools internally manipulate objects as sets (e.g. hwloc-calc and hwloc-bind).
They translate each input location into a hexidecimal location.
When I/O or Misc objects are used, they are translated into the set
of processors (or NUMA nodes) that are close to the given object
(because I/O or Misc objects do not contain processors or NUMA nodes).
.
.PP
If multiple locations are specified on the command-line (delimited by whitespace),
they are combined (the overall location is wider).
.
If prefixed with "~", the given location
will be cleared instead of added to the current list of locations. If
prefixed with "x", the given location will be and'ed instead of added
to the current list. If prefixed with "^", the given location will be
xor'ed.
.
.PP
More complex operations may be performed by using
.IR hwloc-calc
to compute intermediate values.
.
.SS hwloc Objects
.
.PP
Objects in tuples can be any of the following strings
.
(listed from "biggest" to "smallest"):
.
.TP 10
.B machine
A set of processors and memory.
.
.TP
.B numanode
A NUMA node; a set of processors around memory which the processors
can directly access.
.
If \fBhbm\fR is used instead of \fBnumanode\fR in locations,
command-line tools only consider high-bandwidth memory nodes such as Intel Xeon Phi MCDRAM.
.
.TP
.B package
Typically a physical package or chip, that goes into a package,
it is a grouping of one or more processors.
.
.TP
.B l1cache ... l5cache
A data (or unified) cache.
.
.TP
.B l1icache ... l3icache
An instruction cache.
.
.TP
.B core
A single, physical processing unit which may still contain multiple
logical processors, such as hardware threads.
.
.TP
.B pu
Short for
.I processor unit
(not
.IR process !).
The smallest physical execution unit that hwloc recognizes. For
example, there may be multiple PUs on a core (e.g.,
hardware threads).
.PP
\fBosdev\fR, \fBpcidev\fR, \fBbridge\fR, and \fBmisc\fR may also be used
to specify special devices although some of them have dedicated identification
ways as explained in \fBLocation Specification\fR.
.
.PP
Finally, note that an object can be denoted by its numeric "depth" in
the topology graph.
.
.SS hwloc Indexes
Indexes are integer values that uniquely specify a given object of a
specific type. Indexes can be expressed either as
.I logical
values or
.I physical
values. Most hwloc utilities accept logical indexes by default.
Passing
.B --physical
switches to physical/OS indexes.
Both logical and physical indexes are described on this man page.
.
.PP
.I Logical
indexes are relative to the object order in the output from the
lstopo command. They always start with 0 and increment by 1 for each
successive object.
.
.PP
.I Physical
indexes are how the operating system refers to objects. Note that
while physical indexes are non-negative integer values, the hardware
and/or operating system may choose arbitrary values -- they may not
start with 0, and successive objects may not have consecutive values.
.
.PP
For example, if the first few lines of lstopo -p output are the
following:
.
Machine (47GB)
NUMANode P#0 (24GB) + Package P#0 + L3 (12MB)
L2 (256KB) + L1 (32KB) + Core P#0 + PU P#0
L2 (256KB) + L1 (32KB) + Core P#1 + PU P#0
L2 (256KB) + L1 (32KB) + Core P#2 + PU P#0
L2 (256KB) + L1 (32KB) + Core P#8 + PU P#0
L2 (256KB) + L1 (32KB) + Core P#9 + PU P#0
L2 (256KB) + L1 (32KB) + Core P#10 + PU P#0
NUMANode P#1 (24GB) + Package P#1 + L3 (12MB)
L2 (256KB) + L1 (32KB) + Core P#0 + PU P#0
L2 (256KB) + L1 (32KB) + Core P#1 + PU P#0
L2 (256KB) + L1 (32KB) + Core P#2 + PU P#0
L2 (256KB) + L1 (32KB) + Core P#8 + PU P#0
L2 (256KB) + L1 (32KB) + Core P#9 + PU P#0
L2 (256KB) + L1 (32KB) + Core P#10 + PU P#0
In this example, the first core on the second package is logically
number 6 (i.e., logically the 7th core, starting from 0). Its
physical index is 0, but note that another core
.I also
has a physical index of 0. Hence, physical indexes may only be
relevant within the scope of their parent (or set of ancestors).
In this example, to uniquely identify logical core 6 with
physical indexes, you must specify (at a minimum) both a package and a
core: package 1, core 0.
.PP
Index values, regardless of whether they are logical or physical, can
be expressed in several different forms (where X, Y, and N are
positive integers):
.
.TP 10
.B X
The object with index value X.
.
.TP
.B X-Y
All the objects with index values >= X and <= Y.
.
.TP
.B X-
All the objects with index values >= X.
.
.TP
.B X:N
N objects starting with index X, possibly wrapping around the end of
the level.
.
.TP
.B all
A special index value indicating all valid index values.
.
.TP
.B odd
A special index value indicating all valid odd index values.
.
.TP
.B even
A special index value indicating all valid even index values.
.
.PP
.IR REMEMBER :
hwloc's command line tools accept
.I logical
indexes for location values by default.
Use
.BR --physical " and " --logical
to switch from one mode to another.
.
.\" **************************
.\" See also section
.\" **************************
.SH SEE ALSO
.
hwloc's command line tool documentation: lstopo(1), hwloc-bind(1),
hwloc-calc(1), hwloc-distrib(1), hwloc-ps(1).
.
.PP
hwloc has many C API functions, each of which have their own man page.
Some top-level man pages are also provided, grouping similar functions
together. A few good places to start might include:
hwlocality_objects(3), hwlocality_types(3), hwlocality_creation(3),
hwlocality_cpuset(3), hwlocality_information(3), and
hwlocality_binding(3).
.
.PP
For a listing of all available hwloc man pages, look at all "hwloc*"
files in the man1 and man3 directories.

93
linx64/mpi/openmpi/share/man/man7/ompi_crcp.7
View File

@@ -1,93 +0,0 @@
.\"
.\" Man page for OMPI's CRCP Functionality
.\"
.\" .TH name section center-footer left-footer center-header
.TH OMPI_CRCP 7 "Mar 26, 2019" "4.0.1" "Open MPI"
.\" **************************
.\" Name Section
.\" **************************
.SH NAME
.
OMPI_CRCP \- Open MPI MCA Checkpoint/Restart Coordination Protocol (CRCP) Framework:
Overview of Open MPI's CRCP framework, and selected modules. Open MPI 4.0.1
.
.\" **************************
.\" Description Section
.\" **************************
.SH DESCRIPTION
.
.PP
The CRCP Framework is used by Open MPI for the encapsulation of various
Checkpoint/Restart Coordination Protocols (e.g., Coordinated, Uncoordinated,
Message/Communication Induced, ...).
.
.\" **************************
.\" General Process Requirements Section
.\" **************************
.SH GENERAL PROCESS REQUIREMENTS
.PP
In order for a process to use the Open MPI CRCP components it must adhear to a
few programmatic requirements.
.PP
First, the program must call \fIMPI_INIT\fR early in its execution.
.PP
The program must call \fIMPI_FINALIZE\fR before termination.
.PP
A user may initiate a checkpoint of a parallel application by using the
ompi-checkpoint(1) and ompi-restart(1) commands.
.
.\" **********************************
.\" Available Components Section
.\" **********************************
.SH AVAILABLE COMPONENTS
.PP
Open MPI currently ships with one CRCP component: \fIcoord\fR.
.
.PP
The following MCA parameters apply to all components:
.
.TP 4
crcp_base_verbose
Set the verbosity level for all components. Default is 0, or silent except on error.
.
.\" Coord Component
.\" ******************
.SS coord CRCP Component
.PP
The \fIcoord\fR component implements a Coordinated Checkpoint/Restart
Coordination Protocol similar to the one implemented in LAM/MPI.
.
.PP
The \fIcoord\fR component has the following MCA parameters:
.
.TP 4
crcp_coord_priority
The component's priority to use when selecting the most appropriate component
for a run.
.
.TP 4
crcp_coord_verbose
Set the verbosity level for this component. Default is 0, or silent except on
error.
.
.\" Special 'none' option
.\" ************************
.SS none CRCP Component
.PP
The \fInone\fP component simply selects no CRCP component. All of the CRCP
function calls return immediately with OMPI_SUCCESS.
.
.PP
This component is the last component to be selected by default. This means that if
another component is available, and the \fInone\fP component was not explicity
requested then Open MPI will attempt to activate all of the available components
before falling back to this component.
.
.\" **************************
.\" See Also Section
.\" **************************
.
.SH SEE ALSO
ompi-checkpoint(1), ompi-restart(1), opal-checkpoint(1), opal-restart(1),
orte_snapc(7), orte_filem(7), opal_crs(7)
.

179
linx64/mpi/openmpi/share/man/man7/opal_crs.7
View File

@@ -1,179 +0,0 @@
.\"
.\" Copyright (c) 2004-2010 The Trustees of Indiana University and Indiana
.\" University Research and Technology
.\" Corporation. All rights reserved.
.\" Copyright (c) 2009 Sun Microsystems, Inc. All rights reserved.
.\"
.\" Man page for OPAL's CRS Functionality
.\"
.\" .TH name section center-footer left-footer center-header
.TH OPAL_CRS 7 "Mar 26, 2019" "4.0.1" "Open MPI"
.\" **************************
.\" Name Section
.\" **************************
.SH NAME
.
OPAL_CRS \- Open PAL MCA Checkpoint/Restart Service (CRS): Overview of Open PAL's
CRS framework, and selected modules. Open MPI 4.0.1.
.
.\" **************************
.\" Description Section
.\" **************************
.SH DESCRIPTION
.
.PP
Open PAL can involuntarily checkpoint and restart sequential programs.
Doing so requires that Open PAL was compiled with thread support and
that the back-end checkpointing systems are available at run-time.
.
.SS Phases of Checkpoint / Restart
.PP
Open PAL defines three phases for checkpoint / restart support in a
procress:
.
.TP 4
Checkpoint
When the checkpoint request arrives, the procress is notified of the
request before the checkpoint is taken.
.
.TP 4
Continue
After a checkpoint has successfully completed, the same process as the
checkpoint is notified of its successful continuation of execution.
.
.TP 4
Restart
After a checkpoint has successfully completed, a new / restarted
process is notified of its successful restart.
.
.PP
The Continue and Restart phases are identical except for the process
in which they are invoked. The Continue phase is invoked in the same process
as the Checkpoint phase was invoked. The Restart phase is only invoked in newly
restarted processes.
.
.\" **************************
.\" General Process Requirements Section
.\" **************************
.SH GENERAL PROCESS REQUIREMENTS
.PP
In order for a process to use the Open PAL CRS components it must adhear to a
few programmatic requirements.
.PP
First, the program must call \fIOPAL_INIT\fR early in its execution. This
should only be called once, and it is not possible to checkpoint the process
without it first having called this function.
.PP
The program must call \fIOPAL_FINALIZE\fR before termination. This does a
significant amount of cleanup. If it is not called, then it is very likely that
remnants are left in the filesystem.
.PP
To checkpoint and restart a process you must use the Open PAL tools to do
so. Using the backend checkpointer's checkpoint and restart tools will lead
to undefined behavior.
To checkpoint a process use \fIopal_checkpoint\fR (opal_checkpoint(1)).
To restart a process use \fIopal_restart\fR (opal_restart(1)).
.
.\" **********************************
.\" Available Components Section
.\" **********************************
.SH AVAILABLE COMPONENTS
.PP
Open PAL ships with two CRS components: \fIself\fR and \fIblcr\fR.
.
.PP
The following MCA parameters apply to all components:
.
.TP 4
crs_base_verbose
Set the verbosity level for all components. Default is 0, or silent except on error.
.
.\" Self Component
.\" ******************
.SS self CRS Component
.PP
The \fIself\fR component invokes user-defined functions to save and restore
checkpoints. It is simply a mechanism for user-defined functions to be invoked
at Open PAL's Checkpoint, Continue, and Restart phases. Hence, the only data
that is saved during the checkpoint is what is written in the user's checkpoint
function. No libary state is saved at all.
.
.PP
As such, the model for the \fIself\fR component is slightly differnt than for
other components. Specifically, the Restart function is not invoked in the same
process image of the process that was checkpointed. The Restart phase is
invoked during \fBOPAL_INIT\fR of the new instance of the applicaiton (i.e., it
starts over from main()).
.
.PP
The \fIself\fR component has the following MCA parameters:
.TP 4
crs_self_prefix
Speficy a string prefix for the name of the checkpoint, continue, and restart
functions that Open PAL will invoke during the respective stages. That is,
by specifying "-mca crs_self_prefix foo" means that Open PAL expects to find
three functions at run-time:
int foo_checkpoint()
int foo_continue()
int foo_restart()
By default, the prefix is set to "opal_crs_self_user".
.
.TP 4
crs_self_priority
Set the \fIself\fR components default priority
.
.TP 4
crs_self_verbose
Set the verbosity level. Default is 0, or silent except on error.
.
.TP 4
crs_self_do_restart
This is mostly internally used. A general user should never need to set this
value. This is set to non-0 when a the new process should invoke the restart
callback in \fIOPAL_INIT\fR. Default is 0, or normal execution.
.
.\" BLCR Component
.\" ******************
.SS blcr CRS Component
.PP
The Berkeley Lab Checkpoint/Restart (BLCR) single-process checkpoint is a
software system developed at Lawrence Berkeley National Laboratory. See the
project website for more details:
\fI http://ftg.lbl.gov/CheckpointRestart/CheckpointRestart.shtml \fR
.
.PP
The \fIblcr\fR component has the following MCA parameters:
.TP 4
crs_blcr_priority
Set the \fIblcr\fR components default priority.
.
.TP 4
crs_blcr_verbose
Set the verbosity level. Default is 0, or silent except on error.
.
.\" Special 'none' option
.\" ************************
.SS none CRS Component
.PP
The \fInone\fP component simply selects no CRS component. All of the CRS
function calls return immediately with OPAL_SUCCESS.
.
.PP
This component is the last component to be selected by default. This means that if
another component is available, and the \fInone\fP component was not explicity
requested then OPAL will attempt to activate all of the available components
before falling back to this component.
.
.\" **************************
.\" See Also Section
.\" **************************
.
.SH SEE ALSO
opal_checkpoint(1), opal_restart(1)
.\", orte_crs(7), ompi_crs(7)

92
linx64/mpi/openmpi/share/man/man7/orte_filem.7
View File

@@ -1,92 +0,0 @@
.\"
.\" Copyright (c) 2004-2007 The Trustees of Indiana University and Indiana
.\" University Research and Technology
.\" Corporation. All rights reserved.
.\" Copyright (c) 2008-2009 Sun Microsystems, Inc. All rights reserved.
.\"
.\" Man page for ORTE's FileM Functionality
.\"
.\" .TH name section center-footer left-footer center-header
.TH ORTE_FILEM 7 "Mar 26, 2019" "4.0.1" "Open MPI"
.\" **************************
.\" Name Section
.\" **************************
.SH NAME
.
ORTE_FILEM \- Open RTE MCA File Management (FileM) Framework: Overview of Open RTE's
FileM framework, and selected modules. Open MPI 4.0.1
.
.\" **************************
.\" Description Section
.\" **************************
.SH DESCRIPTION
.
.PP
FileM is a utility framework used by OpenRTE for a variety of purposes, including
the transport of checkpoint files, preloading user binaries, and preloading of user files.
.
.\" **********************************
.\" Available Components Section
.\" **********************************
.SH AVAILABLE COMPONENTS
.PP
Open RTE currently ships with one FileM component: \fIrsh\fR.
.
.PP
The following MCA parameters apply to all components:
.
.TP 4
filem_base_verbose
Set the verbosity level for all components. Default is 0, or silent except on
error.
.
.
.\" rsh Component
.\" ******************
.SS rsh FileM Component
.PP
The \fIrsh\fR component uses \fIrcp\fP or \fIscp\fP to do its file transfers. This component
requires the use of passwordless \fIrsh\fP or \fIssh\fP between all nodes.
.
.PP
The \fIrsh\fR component has the following MCA parameters:
.
.TP 4
filem_rsh_priority
The component's priority to use when selecting the most appropriate component
for a run.
.
.TP 4
filem_rsh_verbose
Set the verbosity level for this component. Default is 0, or silent except on
error.
.
.TP 4
filem_rsh_rcp
The program to use to copy files. Generally will be rcp or scp.
.
.TP 4
filem_rsh_rsh
The program used to remotely log into a given machine and remove files.
Generally will be rsh or ssh.
.
.\" Special 'none' option
.\" ************************
.SS none FileM Component
.PP
The \fInone\fP component simply selects no FileM component. All of the FileM
function calls return immediately with ORTE_SUCCESS.
.
.PP
This component is the last component to be selected by default. This means that if
another component is available, and the \fInone\fP component was not explicity
requested then ORTE will attempt to activate all of the available components
before falling back to this component.
.
.\" **************************
.\" See Also Section
.\" **************************
.
.SH SEE ALSO
orte-checkpoint(1), orte-restart(1), opal-checkpoint(1), opal-restart(1), orte_snapc(7), opal_crs(7)
.

197
linx64/mpi/openmpi/share/man/man7/orte_hosts.7
View File

@@ -1,197 +0,0 @@
.\"
.\" Copyright (c) 2008 Los Alamos National Security, LLC All rights reserved.
.\" Copyright (c) 2008-2009 Sun Microsystems, Inc. All rights reserved.
.\"
.\" Man page for ORTE's Hostfile functionality
.\"
.\" .TH name section center-footer left-footer center-header
.TH ORTE_HOSTS 7 "Mar 26, 2019" "4.0.1" "Open MPI"
.\" **************************
.\" Name Section
.\" **************************
.SH NAME
.
ORTE_HOSTS \- OpenRTE Hostfile and HOST Behavior: Overview of OpenRTE's support for user-supplied
hostfiles and comma-delimited lists of hosts
.
.\" **************************
.\" Description Section
.\" **************************
.SH DESCRIPTION
.
.PP
OpenRTE supports several levels of user-specified host lists based on an established
precedence order. Users can specify a \fIdefault hostfile\fP that contains a list of
nodes available to all app_contexts given on the command line. Only \fIone\fP default
hostfile can be provided for any job. In addition, users
can specify a \fIhostfile\fP that contains a list of nodes to be used for a specific
app_context, or can provide a comma-delimited list of nodes to be used for that
app_context via the \fI-host\fP command line option.
.sp
The precedence order applied to these various options depends to some extent on
the local environment. The following table illustrates how host and hostfile directives
work together to define the set of hosts upon which a job will execute
in the absence of a resource manager (RM):
.sp
.nf
default
hostfile host hostfile Result
---------- ------ ---------- -----------------------------------------
unset unset unset Job is co-located with mpirun
unset set unset Host defines resource list for the job
unset unset set Hostfile defines resource list for the job
unset set set Hostfile defines resource list for the job,
then host filters the list to define the final
set of nodes available to each application
within the job
set unset unset Default hostfile defines resource list for the job
set set unset Default hostfile defines resource list for the job,
then host filters the list to define the final
set of nodes available to each application
within the job
set set set Default hostfile defines resource list for the job,
then hostfile filters the list, and then host filters
the list to define the final set of nodes available
to each application within the job
.fi
.sp
This changes somewhat in the presence of a RM as that entity specifies the
initial allocation of nodes. In this case, the default hostfile, hostfile and host
directives are all used to filter the RM's specification so that a user can utilize different
portions of the allocation for different jobs. This is done according to the same precedence
order as in the prior table, with the RM providing the initial pool of nodes.
.sp
.
.\" **************************
.\" Relative Indexing
.\" **************************
.SH RELATIVE INDEXING
.
.PP
Once an initial allocation has been specified (whether by an RM, default hostfile, or hostfile),
subsequent hostfile and -host specifications can be made using relative indexing. This allows a
user to stipulate which hosts are to be used for a given app_context without specifying the
particular host name, but rather its relative position in the allocation.
.sp
This can probably best be understood through consideration of a few examples. Consider the case
where an RM has allocated a set of nodes to the user named "foo1, foo2, foo3, foo4". The user
wants the first app_context to have exclusive use of the first two nodes, and a second app_context
to use the last two nodes. Of course, the user could printout the allocation to find the names
of the nodes allocated to them and then use -host to specify this layout, but this is cumbersome
and would require hand-manipulation for every invocation.
.sp
A simpler method is to utilize OpenRTE's relative indexing capability to specify the desired
layout. In this case, a command line of:
.sp
mpirun -pernode -host +n1,+n2 ./app1 : -host +n3,+n4 ./app2
.sp
.PP
would provide the desired pattern. The "+" syntax indicates that the information is being
provided as a relative index to the existing allocation. Two methods of relative indexing
are supported:
.sp
.TP
.B +n<#>
A relative index into the allocation referencing the <#> node. OpenRTE will substitute
the <#> node in the allocation
.
.
.TP
.B +e[:<#>]
A request for <#> empty nodes - i.e., OpenRTE is to substitute this reference with
<#> nodes that have not yet been used by any other app_context. If the ":<#>" is not
provided, OpenRTE will substitute the reference with all empty nodes. Note that OpenRTE
does track the empty nodes that have been assigned in this manner, so multiple
uses of this option will result in assignment of unique nodes up to the limit of the
available empty nodes. Requests for more empty nodes than are available will generate
an error.
.sp
.PP
Relative indexing can be combined with absolute naming of hosts in any arbitrary manner,
and can be used in hostfiles as well as with the -host command line option. In addition,
any slot specification provided in hostfiles will be respected - thus, a user can specify
that only a certain number of slots from a relative indexed host are to be used for a
given app_context.
.sp
Another example may help illustrate this point. Consider the case where a user has a default
hostfile containing:
.sp
.nf
dummy1 slots=4
dummy2 slots=4
dummy3 slots=4
dummy4 slots=4
dummy5 slots=4
.fi
.sp
.PP
This may, for example, be a hostfile that describes a set of commonly-used resources that
the user wishes to execute applications against. For this particular application, the user
plans to map byslot, and wants the first two ranks to be on the second node of any allocation,
the next ranks to land on an empty node, have one rank specifically on dummy4, the next rank
to be on the second node of the allocation again, and finally any remaining ranks to be on
whatever empty nodes are left. To accomplish this, the user provides a hostfile of:
.sp
.nf
+n2 slots=2
+e:1
dummy4 slots=1
+n2
+e
.fi
.sp
.PP
The user can now use this information in combination with OpenRTE's sequential mapper to
obtain their specific layout:
.sp
.nf
mpirun --default-hostfile dummyhosts -hostfile mylayout -mca rmaps seq ./my_app
.fi
.sp
.PP
which will result in:
.nf
.sp
rank0 being mapped to dummy3
.br
rank1 to dummy1 as the first empty node
.br
rank2 to dummy4
.br
rank3 to dummy3
.br
rank4 to dummy2 and rank5 to dummy5 as the last remaining unused nodes
.sp
.fi
Note that the sequential mapper ignores the number of slots arguments as it only
maps one rank at a time to each node in the list.
.sp
If the default round-robin mapper had been used, then the mapping would have resulted in:
.sp
.nf
ranks 0 and 1 being mapped to dummy3 since two slots were specified
.br
ranks 2-5 on dummy1 as the first empty node, which has four slots
.br
rank6 on dummy4 since the hostfile specifies only a single slot from that node is to be used
.br
ranks 7 and 8 on dummy3 since only two slots remain available
.br
ranks 9-12 on dummy2 since it is the next available empty node and has four slots
.br
ranks 13-16 on dummy5 since it is the last remaining unused node and has four slots
.fi
.sp
.PP
Thus, the use of relative indexing can allow for complex mappings to be ported across
allocations, including those obtained from automated resource managers, without the need
for manual manipulation of scripts and/or command lines.
.
.
.\" **************************
.\" See Also Section
.\" **************************
.
.SH SEE ALSO
orterun(1)
.

105
linx64/mpi/openmpi/share/man/man7/orte_snapc.7
View File

@@ -1,105 +0,0 @@
.\"
.\" Copyright (c) 2004-2010 The Trustees of Indiana University and Indiana
.\" University Research and Technology
.\" Corporation. All rights reserved.
.\" Copyright (c) 2008-2009 Sun Microsystems, Inc. All rights reserved.
.\"
.\" Man page for ORTE's SnapC Functionality
.\"
.\" .TH name section center-footer left-footer center-header
.TH ORTE_SNAPC 7 "Mar 26, 2019" "4.0.1" "Open MPI"
.\" **************************
.\" Name Section
.\" **************************
.SH NAME
.
ORTE_SNAPC \- Open RTE MCA Snapshot Coordination (SnapC) Framework: Overview of
Open RTE's SnapC framework, and selected modules. Open MPI 4.0.1
.
.\" **************************
.\" Description Section
.\" **************************
.SH DESCRIPTION
.
.PP
Open RTE can coordinate the generation of a global snapshot of a parallel job
from many distributed local snapshots. The components in this framework
determine how to: Initiate the checkpoint of the parallel application, gather
together the many distributed local snapshots, and provide the user with a
global snapshot handle reference that can be used to restart the parallel
application.
.
.\" **************************
.\" General Process Requirements Section
.\" **************************
.SH GENERAL PROCESS REQUIREMENTS
.PP
In order for a process to use the Open RTE SnapC components it must adhear to a
few programmatic requirements.
.PP
First, the program must call \fIORTE_INIT\fR early in its execution. This
should only be called once, and it is not possible to checkpoint the process
without it first having called this function.
.PP
The program must call \fIORTE_FINALIZE\fR before termination.
.PP
A user may initiate a checkpoint of a parallel application by using the
orte-checkpoint(1) and orte-restart(1) commands.
.
.\" **********************************
.\" Available Components Section
.\" **********************************
.SH AVAILABLE COMPONENTS
.PP
Open RTE ships with one SnapC component: \fIfull\fR.
.
.PP
The following MCA parameters apply to all components:
.
.TP 4
snapc_base_verbose
Set the verbosity level for all components. Default is 0, or silent except on error.
.
.\" full Component
.\" ******************
.SS full SnapC Component
.PP
The \fIfull\fR component gathers together the local snapshots to the disk local
to the Head Node Process (HNP) before completing the checkpoint of the process. This
component does not currently support replicated HNPs, or timer based gathering
of local snapshot data. This is a 3-tiered hierarchy of coordinators.
.
.PP
The \fIfull\fR component has the following MCA parameters:
.
.TP 4
snapc_full_priority
The component's priority to use when selecting the most appropriate component
for a run.
.
.TP 4
snapc_full_verbose
Set the verbosity level for this component. Default is 0, or silent except on
error.
.
.\" Special 'none' option
.\" ************************
.SS none SnapC Component
.PP
The \fInone\fP component simply selects no SnapC component. All of the SnapC
function calls return immediately with ORTE_SUCCESS.
.
.PP
This component is the last component to be selected by default. This means that if
another component is available, and the \fInone\fP component was not explicity
requested then ORTE will attempt to activate all of the available components
before falling back to this component.
.
.\" **************************
.\" See Also Section
.\" **************************
.
.SH SEE ALSO
orte-checkpoint(1), orte-restart(1), opal-checkpoint(1), opal-restart(1),
orte_filem(7), opal_crs(7)
.

66
linx64/mpi/openmpi/share/man/man7/orte_sstore.7
View File

@@ -1,66 +0,0 @@
.\"
.\" Copyright (c) 2010 The Trustees of Indiana University and Indiana
.\" University Research and Technology
.\" Corporation. All rights reserved.
.\"
.\" Man page for ORTE's SStore Functionality
.\"
.\" .TH name section center-footer left-footer center-header
.TH ORTE_SSTORE 7 "Mar 26, 2019" "4.0.1" "Open MPI"
.\" **************************
.\" Name Section
.\" **************************
.SH NAME
.
Open RTE MCA File Management (SStore) Framework \- Overview of Open RTE's SStore
framework, and selected modules. Open MPI 4.0.1
.
.\" **************************
.\" Description Section
.\" **************************
.SH DESCRIPTION
.
.PP
SStore is a utility framework used by OpenRTE for a variety of purposes, including
the transport of checkpoint files, preloading user binaries, and preloading of user files.
.
.\" **********************************
.\" Available Components Section
.\" **********************************
.SH AVAILABLE COMPONENTS
.PP
The following MCA parameters apply to all components:
.
.TP 4
sstore_base_verbose
Set the verbosity level for all components. Default is 0, or silent except on
error.
.
.
.\" central Component
.\" ******************
.SS central SStore Component
.PP
The \fIcentral\fR component implements a fully centralized stable storage
mechanism that requires a shared storage medium (e.g., NFS).
.
.PP
The \fIcentral\fR component has the following MCA parameters:
.
.TP 4
sstore_central_priority
The component's priority to use when selecting the most appropriate component
for a run.
.
.TP 4
sstore_central_verbose
Set the verbosity level for this component. Default is 0, or silent except on
error.
.
.\" **************************
.\" See Also Section
.\" **************************
.
.SH SEE ALSO
orte-checkpoint(1), orte-restart(1), opal-checkpoint(1), opal-restart(1), orte_snapc(7), opal_crs(7)
.