-
Notifications
You must be signed in to change notification settings - Fork 13
/
README
171 lines (127 loc) · 5.77 KB
/
README
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
SLURM spank plugins README
==================================
This package includes several SLURM spank plugins developed
at LLNL and used on production compute clusters onsite. A few
of these plugins are only valid when used on LLNL's software
stack (oom-detect.so, for example, requires LLNL-specific patches
to track job's terminated by the OOM killer). However, the
source for all plugins is provided here in the hope that they
might be useful to other plugin developers. The following
is a short description of most of the plugins in this package.
addr-no-randomize
-----------------
The addr-no-randomize plugin allows sysadmins to set a default
policy for address space randomization (when supported and
enabled in the Linux kernel), and provides an option for users
to enable/disable randomization on a per-job basis.
auto-affinity
-----------------
Automatically assign CPU affinity using best-guess defaults.
The default behavior of this plugin attempts to accomodate
multi-threaded apps by assigning more than one CPU per task
if the number of tasks running on the node is evenly divisible
into the number of CPUs. Otherwise, CPU affinity is not enabled
unless the cpus_per_task (cpt) option is specified. The default
behavior may be modified using the --auto-affinity options
listed below. Also, the srun(1) --cpu_bind option is processed
after auto-affinity, and thus may be used to override any CPU
affinity settings from this module.
This plugin should not be used alone on systems using node
sharing. In that case, it should be used along with
the cpuset plugin below (and auto-affinity.so should be listed
*after* cpuset.so in the plugstack.conf).
cpuset
-----------------
The cpuset plugin uses Linux cpusets to constrain jobs to the
number of CPUs they have been allocated on nodes. The plugin
is specifically designed for sytems sharing nodes and using CPU
scheduling (i.e. using the select/cons_res plugin). The plugin
will not work on systems where CPUs are oversubscribed to jobs
(i.e. strict node sharing without the use of select/cons_res).
The plugin also has a pam_slurm_cpuset counterpart, which
replaces pam_slurm and serves an identical functionality,
except that user login sessions are constrained to their
currently allocated CPUs on a node.
The cpuset plugin requires the SGI libbitmask and libcpuset
libraries available from
http://oss.sgi.com/projects/cpusets
(See also cpuset/README)
iorelay
-----------------
The iorelay plugin is an experimental proof-of-concept plugin
for remounting required filesystems for a parallel job from
the first allocated node to all others. It is meant to reduce
the load on global NFS servers.
It has not been used in production.
iotrace
-----------------
The iotrace plugin is another experimental plugin which
uses "plasticfs" to log filesystem access on a per-job
basis.
oom-detect
-----------------
The oom-detect plugin detects jobs that have been victims
of the OOM killer using some special code added to the LLNL
Linux kernel. As tasks exit after having been killed by
the OOM killer, a message is printed to the user's stderr
along with some memory information about the task.
overcommit-memory
-----------------
The overcommit-memory plugin is an attempt to allow users
to tune global overcommit behavior of the Linux kernel on
a per-job basis. It is currently buggy and thus not used.
preserve-env
-----------------
The preserve-env plugin adds an srun option
--preserve-slurm-env
which attempts to preserve the current state of all SLURM_*
environment variables in the remotely executed environment. This
is meant solely to be used from an allocation shell with
the syntax
srun -n1 -N1 --pty --preserve-slurm-env $SHELL
as a sort of "remote" allocation shell.
pty
-----------------
The pty plugin provides the SLURM --pty option, introduced
in slurm-1.3, for slurm-1.2. It isn't fully functional at this
point, but is a good example of a complex feature added solely
from a spank plugin.
renice
-----------------
The renice plugin is the same as the example code in the
spank(8) man page. It provides a new srun option "--renice=VALUE"
which allows users to set the nice value of their remote
tasks (down to a minimum value configured by sysadmin).
system-safe
------------------
The system-safe plugin provides an MPI-safe system(3)
replacement through an LD_PRELOAD library (most of the work
is done in system-safe-preload.c). The preloaded library
interposes a version of system(3) that does not fork. Instead,
the command line is passed through a pipe to a copy of the
program which was pre-forked before MPI_Init(). The return
value of the real system() call is passed back through the
pipe and returned to the calling application, for which there
is no noticable difference with the real system(3).
use-env
------------------
The use-env plugin allows system administrators and users to
modify the environment of SLURM jobs using a set of simple
yet very flexible config files. Environment variables can
be overridden, set only if unset, set based on conditional
syntax, and even defined in a per-task context. The config
files have access to key slurm variables such as SLURM_NNODES,
SLURM_NPROCS, etc., so variables can even be defined differently
depending of the size of the job.
See README.use-env for further information.
setsched
------------------
The setsched plugin allows system administrators to configure a
particular kernel scheduling policy that can be applied to tasks
spawned by slurmstepd. The policy can be used by default or not.
In all cases, users can enable/disable as soon as it is described
in the configuration, using --setsched=[yes|no|auto].
setsched spank module configuration looks like the following
(default parameters used, policies are configured using numerical
values) :
optional setsched.so policy=1 priority=10 default=disabled