1salloc(1) Slurm Commands salloc(1)
2
6 salloc - Obtain a Slurm job allocation (a set of nodes), execute a com‐
7 mand, and then release the allocation when the command is finished.
8
11 salloc [OPTIONS(0)...] [ : [OPTIONS(N)...]] command(0) [args(0)...]
12 Option(s) define multiple jobs in a co-scheduled heterogeneous job.
14 For more details about heterogeneous jobs see the document
15 https://slurm.schedmd.com/heterogeneous_jobs.html
16
19 salloc is used to allocate a Slurm job allocation, which is a set of
20 resources (nodes), possibly with some set of constraints (e.g. number
21 of processors per node). When salloc successfully obtains the
22 requested allocation, it then runs the command specified by the user.
23 Finally, when the user specified command is complete, salloc relin‐
24 quishes the job allocation.
25 The command may be any program the user wishes. Some typical commands
27 are xterm, a shell script containing srun commands, and srun (see the
28 EXAMPLES section). If no command is specified, then the value of Sal‐
29 locDefaultCommand in slurm.conf is used. If SallocDefaultCommand is not
30 set, then salloc runs the user's default shell.
31 The following document describes the influence of various options on
33 the allocation of cpus to jobs and tasks.
34 https://slurm.schedmd.com/cpu_management.html
35 NOTE: The salloc logic includes support to save and restore the termi‐
37 nal line settings and is designed to be executed in the foreground. If
38 you need to execute salloc in the background, set its standard input to
39 some file, for example: "salloc -n16 a.out </dev/null &"
40
43 If salloc is unable to execute the user command, it will return 1 and
44 print errors to stderr. Else if success or if killed by signals HUP,
45 INT, KILL, or QUIT: it will return 0.
46
49 If provided, the command is resolved in the following order:
50 1. If command starts with ".", then path is constructed as: current
52 working directory / command
53 2. If command starts with a "/", then path is considered absolute.
55 3. If command can be resolved through PATH. See path_resolution(7).
57 4. If command is in current working directory.
59 Current working directory is the calling process working directory
61 unless the --chdir argument is passed, which will override the current
62 working directory.
63
66 -A, --account=<account>
67 Charge resources used by this job to specified account. The
68 account is an arbitrary string. The account name may be changed
69 after job submission using the scontrol command.
70 --acctg-freq
73 Define the job accounting and profiling sampling intervals.
74 This can be used to override the JobAcctGatherFrequency parame‐
75 ter in Slurm's configuration file, slurm.conf. The supported
76 format is as follows:
77 --acctg-freq=<datatype>=<interval>
79 where <datatype>=<interval> specifies the task sam‐
80 pling interval for the jobacct_gather plugin or a
81 sampling interval for a profiling type by the
82 acct_gather_profile plugin. Multiple, comma-sepa‐
83 rated <datatype>=<interval> intervals may be speci‐
84 fied. Supported datatypes are as follows:
85 task=<interval>
87 where <interval> is the task sampling inter‐
88 val in seconds for the jobacct_gather plugins
89 and for task profiling by the
90 acct_gather_profile plugin. NOTE: This fre‐
91 quency is used to monitor memory usage. If
92 memory limits are enforced the highest fre‐
93 quency a user can request is what is config‐
94 ured in the slurm.conf file. They can not
95 turn it off (=0) either.
96 energy=<interval>
98 where <interval> is the sampling interval in
99 seconds for energy profiling using the
100 acct_gather_energy plugin
101 network=<interval>
103 where <interval> is the sampling interval in
104 seconds for infiniband profiling using the
105 acct_gather_infiniband plugin.
106 filesystem=<interval>
108 where <interval> is the sampling interval in
109 seconds for filesystem profiling using the
110 acct_gather_filesystem plugin.
111 The default value for the task sampling
113 interval
114 is 30. The default value for all other intervals is 0. An
115 interval of 0 disables sampling of the specified type. If the
116 task sampling interval is 0, accounting information is collected
117 only at job termination (reducing Slurm interference with the
118 job).
119 Smaller (non-zero) values have a greater impact upon job perfor‐
120 mance, but a value of 30 seconds is not likely to be noticeable
121 for applications having less than 10,000 tasks.
122 -B --extra-node-info=<sockets[:cores[:threads]]>
125 Restrict node selection to nodes with at least the specified
126 number of sockets, cores per socket and/or threads per core.
127 NOTE: These options do not specify the resource allocation size.
128 Each value specified is considered a minimum. An asterisk (*)
129 can be used as a placeholder indicating that all available
130 resources of that type are to be utilized. Values can also be
131 specified as min-max. The individual levels can also be speci‐
132 fied in separate options if desired:
133 --sockets-per-node=<sockets>
134 --cores-per-socket=<cores>
135 --threads-per-core=<threads>
136 If task/affinity plugin is enabled, then specifying an alloca‐
137 tion in this manner also results in subsequently launched tasks
138 being bound to threads if the -B option specifies a thread
139 count, otherwise an option of cores if a core count is speci‐
140 fied, otherwise an option of sockets. If SelectType is config‐
141 ured to select/cons_res, it must have a parameter of CR_Core,
142 CR_Core_Memory, CR_Socket, or CR_Socket_Memory for this option
143 to be honored. If not specified, the scontrol show job will
144 display 'ReqS:C:T=*:*:*'. This option applies to job alloca‐
145 tions.
146 --bb=<spec>
149 Burst buffer specification. The form of the specification is
150 system dependent. Note the burst buffer may not be accessible
151 from a login node, but require that salloc spawn a shell on one
152 of it's allocated compute nodes. See the description of Sal‐
153 locDefaultCommand in the slurm.conf man page for more informa‐
154 tion about how to spawn a remote shell.
155 --bbf=<file_name>
158 Path of file containing burst buffer specification. The form of
159 the specification is system dependent. Also see --bb. Note the
160 burst buffer may not be accessible from a login node, but
161 require that salloc spawn a shell on one of it's allocated com‐
162 pute nodes. See the description of SallocDefaultCommand in the
163 slurm.conf man page for more information about how to spawn a
164 remote shell.
165 --begin=<time>
168 Defer eligibility of this job allocation until the specified
169 time.
170 Time may be of the form HH:MM:SS to run a job at a specific time
172 of day (seconds are optional). (If that time is already past,
173 the next day is assumed.) You may also specify midnight, noon,
174 fika (3 PM) or teatime (4 PM) and you can have a time-of-day
175 suffixed with AM or PM for running in the morning or the
176 evening. You can also say what day the job will be run, by
177 specifying a date of the form MMDDYY or MM/DD/YY YYYY-MM-DD.
178 Combine date and time using the following format
179 YYYY-MM-DD[THH:MM[:SS]]. You can also give times like now +
180 count time-units, where the time-units can be seconds (default),
181 minutes, hours, days, or weeks and you can tell Slurm to run the
182 job today with the keyword today and to run the job tomorrow
183 with the keyword tomorrow. The value may be changed after job
184 submission using the scontrol command. For example:
185 --begin=16:00
186 --begin=now+1hour
187 --begin=now+60 (seconds by default)
188 --begin=2010-01-20T12:34:00
189 Notes on date/time specifications:
192 - Although the 'seconds' field of the HH:MM:SS time specifica‐
193 tion is allowed by the code, note that the poll time of the
194 Slurm scheduler is not precise enough to guarantee dispatch of
195 the job on the exact second. The job will be eligible to start
196 on the next poll following the specified time. The exact poll
197 interval depends on the Slurm scheduler (e.g., 60 seconds with
198 the default sched/builtin).
199 - If no time (HH:MM:SS) is specified, the default is
200 (00:00:00).
201 - If a date is specified without a year (e.g., MM/DD) then the
202 current year is assumed, unless the combination of MM/DD and
203 HH:MM:SS has already passed for that year, in which case the
204 next year is used.
205 --bell Force salloc to ring the terminal bell when the job allocation
208 is granted (and only if stdout is a tty). By default, salloc
209 only rings the bell if the allocation is pending for more than
210 ten seconds (and only if stdout is a tty). Also see the option
211 --no-bell.
212 --cluster-constraint=<list>
215 Specifies features that a federated cluster must have to have a
216 sibling job submitted to it. Slurm will attempt to submit a sib‐
217 ling job to a cluster if it has at least one of the specified
218 features.
219 --comment=<string>
222 An arbitrary comment.
223 -C, --constraint=<list>
226 Nodes can have features assigned to them by the Slurm adminis‐
227 trator. Users can specify which of these features are required
228 by their job using the constraint option. Only nodes having
229 features matching the job constraints will be used to satisfy
230 the request. Multiple constraints may be specified with AND,
231 OR, matching OR, resource counts, etc. (some operators are not
232 supported on all system types). Supported constraint options
233 include:
234 Single Name
236 Only nodes which have the specified feature will be used.
237 For example, --constraint="intel"
238 Node Count
240 A request can specify the number of nodes needed with
241 some feature by appending an asterisk and count after the
242 feature name. For example "--nodes=16 --con‐
243 straint=graphics*4 ..." indicates that the job requires
244 16 nodes and that at least four of those nodes must have
245 the feature "graphics."
246 AND If only nodes with all of specified features will be
248 used. The ampersand is used for an AND operator. For
249 example, --constraint="intel&gpu"
250 OR If only nodes with at least one of specified features
252 will be used. The vertical bar is used for an OR opera‐
253 tor. For example, --constraint="intel|amd"
254 Matching OR
256 If only one of a set of possible options should be used
257 for all allocated nodes, then use the OR operator and
258 enclose the options within square brackets. For example:
259 "--constraint=[rack1|rack2|rack3|rack4]" might be used to
260 specify that all nodes must be allocated on a single rack
261 of the cluster, but any of those four racks can be used.
262 Multiple Counts
264 Specific counts of multiple resources may be specified by
265 using the AND operator and enclosing the options within
266 square brackets. For example: "--con‐
267 straint=[rack1*2&rack2*4]" might be used to specify that
268 two nodes must be allocated from nodes with the feature
269 of "rack1" and four nodes must be allocated from nodes
270 with the feature "rack2".
271 NOTE: This construct does not support multiple Intel KNL
273 NUMA or MCDRAM modes. For example, while "--con‐
274 straint=[(knl&quad)*2&(knl&hemi)*4]" is not supported,
275 "--constraint=[haswell*2&(knl&hemi)*4]" is supported.
276 Specification of multiple KNL modes requires the use of a
277 heterogeneous job.
278 Parenthesis
281 Parenthesis can be used to group like node features
282 together. For example "--con‐
283 straint=[(knl&snc4&flat)*4&haswell*1]" might be used to
284 specify that four nodes with the features "knl", "snc4"
285 and "flat" plus one node with the feature "haswell" are
286 required. All options within parenthesis should be
287 grouped with AND (e.g. "&") operands.
288 --contiguous
291 If set, then the allocated nodes must form a contiguous set.
292 Not honored with the topology/tree or topology/3d_torus plugins,
293 both of which can modify the node ordering.
294 --cores-per-socket=<cores>
297 Restrict node selection to nodes with at least the specified
298 number of cores per socket. See additional information under -B
299 option above when task/affinity plugin is enabled.
300 --cpu-freq =<p1[-p2[:p3]]>
303 Request that job steps initiated by srun commands inside this
305 allocation be run at some requested frequency if possible, on
306 the CPUs selected for the step on the compute node(s).
307 p1 can be [#### | low | medium | high | highm1] which will set
309 the frequency scaling_speed to the corresponding value, and set
310 the frequency scaling_governor to UserSpace. See below for defi‐
311 nition of the values.
312 p1 can be [Conservative | OnDemand | Performance | PowerSave]
314 which will set the scaling_governor to the corresponding value.
315 The governor has to be in the list set by the slurm.conf option
316 CpuFreqGovernors.
317 When p2 is present, p1 will be the minimum scaling frequency and
319 p2 will be the maximum scaling frequency.
320 p2 can be [#### | medium | high | highm1] p2 must be greater
322 than p1.
323 p3 can be [Conservative | OnDemand | Performance | PowerSave |
325 UserSpace] which will set the governor to the corresponding
326 value.
327 If p3 is UserSpace, the frequency scaling_speed will be set by a
329 power or energy aware scheduling strategy to a value between p1
330 and p2 that lets the job run within the site's power goal. The
331 job may be delayed if p1 is higher than a frequency that allows
332 the job to run within the goal.
333 If the current frequency is < min, it will be set to min. Like‐
335 wise, if the current frequency is > max, it will be set to max.
336 Acceptable values at present include:
338 #### frequency in kilohertz
340 Low the lowest available frequency
342 High the highest available frequency
344 HighM1 (high minus one) will select the next highest
346 available frequency
347 Medium attempts to set a frequency in the middle of the
349 available range
350 Conservative attempts to use the Conservative CPU governor
352 OnDemand attempts to use the OnDemand CPU governor (the
354 default value)
355 Performance attempts to use the Performance CPU governor
357 PowerSave attempts to use the PowerSave CPU governor
359 UserSpace attempts to use the UserSpace CPU governor
361 The following informational environment variable is set
364 in the job
365 step when --cpu-freq option is requested.
366 SLURM_CPU_FREQ_REQ
367 This environment variable can also be used to supply the value
369 for the CPU frequency request if it is set when the 'srun' com‐
370 mand is issued. The --cpu-freq on the command line will over‐
371 ride the environment variable value. The form on the environ‐
372 ment variable is the same as the command line. See the ENVIRON‐
373 MENT VARIABLES section for a description of the
374 SLURM_CPU_FREQ_REQ variable.
375 NOTE: This parameter is treated as a request, not a requirement.
377 If the job step's node does not support setting the CPU fre‐
378 quency, or the requested value is outside the bounds of the
379 legal frequencies, an error is logged, but the job step is
380 allowed to continue.
381 NOTE: Setting the frequency for just the CPUs of the job step
383 implies that the tasks are confined to those CPUs. If task con‐
384 finement (i.e., TaskPlugin=task/affinity or TaskPlu‐
385 gin=task/cgroup with the "ConstrainCores" option) is not config‐
386 ured, this parameter is ignored.
387 NOTE: When the step completes, the frequency and governor of
389 each selected CPU is reset to the previous values.
390 NOTE: When submitting jobs with the --cpu-freq option with lin‐
392 uxproc as the ProctrackType can cause jobs to run too quickly
393 before Accounting is able to poll for job information. As a
394 result not all of accounting information will be present.
395 --cpus-per-gpu=<ncpus>
398 Advise Slurm that ensuing job steps will require ncpus proces‐
399 sors per allocated GPU. Requires the --gpus option. Not com‐
400 patible with the --cpus-per-task option.
401 -c, --cpus-per-task=<ncpus>
404 Advise Slurm that ensuing job steps will require ncpus proces‐
405 sors per task. By default Slurm will allocate one processor per
406 task.
407 For instance, consider an application that has 4 tasks, each
409 requiring 3 processors. If our cluster is comprised of
410 quad-processors nodes and we simply ask for 12 processors, the
411 controller might give us only 3 nodes. However, by using the
412 --cpus-per-task=3 options, the controller knows that each task
413 requires 3 processors on the same node, and the controller will
414 grant an allocation of 4 nodes, one for each of the 4 tasks.
415 --deadline=<OPT>
418 remove the job if no ending is possible before this deadline
419 (start > (deadline - time[-min])). Default is no deadline.
420 Valid time formats are:
421 HH:MM[:SS] [AM|PM]
422 MMDD[YY] or MM/DD[/YY] or MM.DD[.YY]
423 MM/DD[/YY]-HH:MM[:SS]
424 YYYY-MM-DD[THH:MM[:SS]]]
425 --delay-boot=<minutes>
428 Do not reboot nodes in order to satisfied this job's feature
429 specification if the job has been eligible to run for less than
430 this time period. If the job has waited for less than the spec‐
431 ified period, it will use only nodes which already have the
432 specified features. The argument is in units of minutes. A
433 default value may be set by a system administrator using the
434 delay_boot option of the SchedulerParameters configuration
435 parameter in the slurm.conf file, otherwise the default value is
436 zero (no delay).
437 -d, --dependency=<dependency_list>
440 Defer the start of this job until the specified dependencies
441 have been satisfied completed. <dependency_list> is of the form
442 <type:job_id[:job_id][,type:job_id[:job_id]]> or
443 <type:job_id[:job_id][?type:job_id[:job_id]]>. All dependencies
444 must be satisfied if the "," separator is used. Any dependency
445 may be satisfied if the "?" separator is used. Many jobs can
446 share the same dependency and these jobs may even belong to dif‐
447 ferent users. The value may be changed after job submission
448 using the scontrol command. Once a job dependency fails due to
449 the termination state of a preceding job, the dependent job will
450 never be run, even if the preceding job is requeued and has a
451 different termination state in a subsequent execution.
452 after:job_id[:jobid...]
454 This job can begin execution after the specified jobs
455 have begun execution.
456 afterany:job_id[:jobid...]
458 This job can begin execution after the specified jobs
459 have terminated.
460 afterburstbuffer:job_id[:jobid...]
462 This job can begin execution after the specified jobs
463 have terminated and any associated burst buffer stage out
464 operations have completed.
465 aftercorr:job_id[:jobid...]
467 A task of this job array can begin execution after the
468 corresponding task ID in the specified job has completed
469 successfully (ran to completion with an exit code of
470 zero).
471 afternotok:job_id[:jobid...]
473 This job can begin execution after the specified jobs
474 have terminated in some failed state (non-zero exit code,
475 node failure, timed out, etc).
476 afterok:job_id[:jobid...]
478 This job can begin execution after the specified jobs
479 have successfully executed (ran to completion with an
480 exit code of zero).
481 expand:job_id
483 Resources allocated to this job should be used to expand
484 the specified job. The job to expand must share the same
485 QOS (Quality of Service) and partition. Gang scheduling
486 of resources in the partition is also not supported.
487 singleton
489 This job can begin execution after any previously
490 launched jobs sharing the same job name and user have
491 terminated. In other words, only one job by that name
492 and owned by that user can be running or suspended at any
493 point in time.
494 -D, --chdir=<path>
497 Change directory to path before beginning execution. The path
498 can be specified as full path or relative path to the directory
499 where the command is executed.
500 --exclusive[=user|mcs]
503 The job allocation can not share nodes with other running jobs
504 (or just other users with the "=user" option or with the "=mcs"
505 option). The default shared/exclusive behavior depends on sys‐
506 tem configuration and the partition's OverSubscribe option takes
507 precedence over the job's option.
508 -F, --nodefile=<node file>
511 Much like --nodelist, but the list is contained in a file of
512 name node file. The node names of the list may also span multi‐
513 ple lines in the file. Duplicate node names in the file will
514 be ignored. The order of the node names in the list is not
515 important; the node names will be sorted by Slurm.
516 --get-user-env[=timeout][mode]
519 This option will load login environment variables for the user
520 specified in the --uid option. The environment variables are
521 retrieved by running something of this sort "su - <username> -c
522 /usr/bin/env" and parsing the output. Be aware that any envi‐
523 ronment variables already set in salloc's environment will take
524 precedence over any environment variables in the user's login
525 environment. The optional timeout value is in seconds. Default
526 value is 3 seconds. The optional mode value control the "su"
527 options. With a mode value of "S", "su" is executed without the
528 "-" option. With a mode value of "L", "su" is executed with the
529 "-" option, replicating the login environment. If mode not
530 specified, the mode established at Slurm build time is used.
531 Example of use include "--get-user-env", "--get-user-env=10"
532 "--get-user-env=10L", and "--get-user-env=S". NOTE: This option
533 only works if the caller has an effective uid of "root". This
534 option was originally created for use by Moab.
535 --gid=<group>
538 Submit the job with the specified group's group access permis‐
539 sions. group may be the group name or the numerical group ID.
540 In the default Slurm configuration, this option is only valid
541 when used by the user root.
542 -G, --gpus=[<type>:]<number>
545 Specify the total number of GPUs required for the job. An
546 optional GPU type specification can be supplied. For example
547 "--gpus=volta:3". Multiple options can be requested in a comma
548 separated list, for example: "--gpus=volta:3,kepler:1". See
549 also the --gpus-per-node, --gpus-per-socket and --gpus-per-task
550 options.
551 --gpu-bind=<type>
554 Bind tasks to specific GPUs. By default every spawned task can
555 access every GPU allocated to the job.
556 Supported type options:
558 closest Bind each task to the GPU(s) which are closest. In a
560 NUMA environment, each task may be bound to more than
561 one GPU (i.e. all GPUs in that NUMA environment).
562 map_gpu:<list>
564 Bind by setting GPU masks on tasks (or ranks) as spec‐
565 ified where <list> is
566 <gpu_id_for_task_0>,<gpu_id_for_task_1>,... GPU IDs
567 are interpreted as decimal values unless they are pre‐
568 ceded with '0x' in which case they interpreted as
569 hexadecimal values. If the number of tasks (or ranks)
570 exceeds the number of elements in this list, elements
571 in the list will be reused as needed starting from the
572 beginning of the list. To simplify support for large
573 task counts, the lists may follow a map with an aster‐
574 isk and repetition count. For example
575 "map_gpu:0*4,1*4". Not supported unless the entire
576 node is allocated to the job.
577 mask_gpu:<list>
579 Bind by setting GPU masks on tasks (or ranks) as spec‐
580 ified where <list> is
581 <gpu_mask_for_task_0>,<gpu_mask_for_task_1>,... The
582 mapping is specified for a node and identical mapping
583 is applied to the tasks on every node (i.e. the lowest
584 task ID on each node is mapped to the first mask spec‐
585 ified in the list, etc.). GPU masks are always inter‐
586 preted as hexadecimal values but can be preceded with
587 an optional '0x'. Not supported unless the entire node
588 is allocated to the job. To simplify support for large
589 task counts, the lists may follow a map with an aster‐
590 isk and repetition count. For example
591 "mask_gpu:0x0f*4,0xf0*4". Not supported unless the
592 entire node is allocated to the job.
593 --gpu-freq=[<type]=value>[,<type=value>][,verbose]
596 Request that GPUs allocated to the job are configured with spe‐
597 cific frequency values. This option can be used to indepen‐
598 dently configure the GPU and its memory frequencies. After the
599 job is completed, the frequencies of all affected GPUs will be
600 reset to the highest possible values. In some cases, system
601 power caps may override the requested values. The field type
602 can be "memory". If type is not specified, the GPU frequency is
603 implied. The value field can either be "low", "medium", "high",
604 "highm1" or a numeric value in megahertz (MHz). If the speci‐
605 fied numeric value is not possible, a value as close as possible
606 will be used. See below for definition of the values. The ver‐
607 bose option causes current GPU frequency information to be
608 logged. Examples of use include "--gpu-freq=medium,memory=high"
609 and "--gpu-freq=450".
610 Supported value definitions:
612 low the lowest available frequency.
614 medium attempts to set a frequency in the middle of the
616 available range.
617 high the highest available frequency.
619 highm1 (high minus one) will select the next highest avail‐
621 able frequency.
622 --gpus-per-node=[<type>:]<number>
625 Specify the number of GPUs required for the job on each node
626 included in the job's resource allocation. An optional GPU type
627 specification can be supplied. For example
628 "--gpus-per-node=volta:3". Multiple options can be requested in
629 a comma separated list, for example:
630 "--gpus-per-node=volta:3,kepler:1". See also the --gpus,
631 --gpus-per-socket and --gpus-per-task options.
632 --gpus-per-socket=[<type>:]<number>
635 Specify the number of GPUs required for the job on each socket
636 included in the job's resource allocation. An optional GPU type
637 specification can be supplied. For example
638 "--gpus-per-socket=volta:3". Multiple options can be requested
639 in a comma separated list, for example:
640 "--gpus-per-socket=volta:3,kepler:1". Requires job to specify a
641 sockets per node count ( --sockets-per-node). See also the
642 --gpus, --gpus-per-node and --gpus-per-task options.
643 --gpus-per-task=[<type>:]<number>
646 Specify the number of GPUs required for the job on each task to
647 be spawned in the job's resource allocation. An optional GPU
648 type specification can be supplied. This option requires the
649 specification of a task count. For example
650 "--gpus-per-task=volta:1". Multiple options can be requested in
651 a comma separated list, for example:
652 "--gpus-per-task=volta:3,kepler:1". Requires job to specify a
653 task count (--nodes). See also the --gpus, --gpus-per-socket
654 and --gpus-per-node options.
655 --gres=<list>
658 Specifies a comma delimited list of generic consumable
659 resources. The format of each entry on the list is
660 "name[[:type]:count]". The name is that of the consumable
661 resource. The count is the number of those resources with a
662 default value of 1. The count can have a suffix of "k" or "K"
663 (multiple of 1024), "m" or "M" (multiple of 1024 x 1024), "g" or
664 "G" (multiple of 1024 x 1024 x 1024), "t" or "T" (multiple of
665 1024 x 1024 x 1024 x 1024), "p" or "P" (multiple of 1024 x 1024
666 x 1024 x 1024 x 1024). The specified resources will be allo‐
667 cated to the job on each node. The available generic consumable
668 resources is configurable by the system administrator. A list
669 of available generic consumable resources will be printed and
670 the command will exit if the option argument is "help". Exam‐
671 ples of use include "--gres=gpu:2,mic:1", "--gres=gpu:kepler:2",
672 and "--gres=help".
673 --gres-flags=<type>
676 Specify generic resource task binding options.
677 disable-binding
679 Disable filtering of CPUs with respect to generic
680 resource locality. This option is currently required to
681 use more CPUs than are bound to a GRES (i.e. if a GPU is
682 bound to the CPUs on one socket, but resources on more
683 than one socket are required to run the job). This
684 option may permit a job to be allocated resources sooner
685 than otherwise possible, but may result in lower job per‐
686 formance.
687 enforce-binding
689 The only CPUs available to the job will be those bound to
690 the selected GRES (i.e. the CPUs identified in the
691 gres.conf file will be strictly enforced). This option
692 may result in delayed initiation of a job. For example a
693 job requiring two GPUs and one CPU will be delayed until
694 both GPUs on a single socket are available rather than
695 using GPUs bound to separate sockets, however the appli‐
696 cation performance may be improved due to improved commu‐
697 nication speed. Requires the node to be configured with
698 more than one socket and resource filtering will be per‐
699 formed on a per-socket basis.
700 -H, --hold
703 Specify the job is to be submitted in a held state (priority of
704 zero). A held job can now be released using scontrol to reset
705 its priority (e.g. "scontrol release <job_id>").
706 -h, --help
709 Display help information and exit.
710 --hint=<type>
713 Bind tasks according to application hints.
714 compute_bound
716 Select settings for compute bound applications: use all
717 cores in each socket, one thread per core.
718 memory_bound
720 Select settings for memory bound applications: use only
721 one core in each socket, one thread per core.
722 [no]multithread
724 [don't] use extra threads with in-core multi-threading
725 which can benefit communication intensive applications.
726 Only supported with the task/affinity plugin.
727 help show this help message
729 -I, --immediate[=<seconds>]
732 exit if resources are not available within the time period spec‐
733 ified. If no argument is given (seconds defaults to 1),
734 resources must be available immediately for the request to suc‐
735 ceed. If defer is configured in SchedulerParameters and sec‐
736 onds=1 the allocation request will fail immediately; defer con‐
737 flicts and takes precedence over this option. By default,
738 --immediate is off, and the command will block until resources
739 become available. Since this option's argument is optional, for
740 proper parsing the single letter option must be followed immedi‐
741 ately with the value and not include a space between them. For
742 example "-I60" and not "-I 60".
743 -J, --job-name=<jobname>
746 Specify a name for the job allocation. The specified name will
747 appear along with the job id number when querying running jobs
748 on the system. The default job name is the name of the "com‐
749 mand" specified on the command line.
750 -K, --kill-command[=signal]
753 salloc always runs a user-specified command once the allocation
754 is granted. salloc will wait indefinitely for that command to
755 exit. If you specify the --kill-command option salloc will send
756 a signal to your command any time that the Slurm controller
757 tells salloc that its job allocation has been revoked. The job
758 allocation can be revoked for a couple of reasons: someone used
759 scancel to revoke the allocation, or the allocation reached its
760 time limit. If you do not specify a signal name or number and
761 Slurm is configured to signal the spawned command at job termi‐
762 nation, the default signal is SIGHUP for interactive and SIGTERM
763 for non-interactive sessions. Since this option's argument is
764 optional, for proper parsing the single letter option must be
765 followed immediately with the value and not include a space
766 between them. For example "-K1" and not "-K 1".
767 -k, --no-kill [=off]
770 Do not automatically terminate a job if one of the nodes it has
771 been allocated fails. The user will assume the responsibilities
772 for fault-tolerance should a node fail. When there is a node
773 failure, any active job steps (usually MPI jobs) on that node
774 will almost certainly suffer a fatal error, but with --no-kill,
775 the job allocation will not be revoked so the user may launch
776 new job steps on the remaining nodes in their allocation.
777 Specify an optional argument of "off" disable the effect of the
779 SALLOC_NO_KILL environment variable.
780 By default Slurm terminates the entire job allocation if any
782 node fails in its range of allocated nodes.
783 -L, --licenses=<license>
786 Specification of licenses (or other resources available on all
787 nodes of the cluster) which must be allocated to this job.
788 License names can be followed by a colon and count (the default
789 count is one). Multiple license names should be comma separated
790 (e.g. "--licenses=foo:4,bar").
791 -M, --clusters=<string>
794 Clusters to issue commands to. Multiple cluster names may be
795 comma separated. The job will be submitted to the one cluster
796 providing the earliest expected job initiation time. The default
797 value is the current cluster. A value of 'all' will query to run
798 on all clusters. Note that the SlurmDBD must be up for this
799 option to work properly.
800 -m, --distribution=
803 arbitrary|<block|cyclic|plane=<options>[:block|cyclic|fcyclic]>
804 Specify alternate distribution methods for remote processes. In
806 salloc, this only sets environment variables that will be used
807 by subsequent srun requests. This option controls the assign‐
808 ment of tasks to the nodes on which resources have been allo‐
809 cated, and the distribution of those resources to tasks for
810 binding (task affinity). The first distribution method (before
811 the ":") controls the distribution of resources across nodes.
812 The optional second distribution method (after the ":") controls
813 the distribution of resources across sockets within a node.
814 Note that with select/cons_res, the number of cpus allocated on
815 each socket and node may be different. Refer to
816 https://slurm.schedmd.com/mc_support.html for more information
817 on resource allocation, assignment of tasks to nodes, and bind‐
818 ing of tasks to CPUs.
819 First distribution method:
821 block The block distribution method will distribute tasks to a
823 node such that consecutive tasks share a node. For exam‐
824 ple, consider an allocation of three nodes each with two
825 cpus. A four-task block distribution request will dis‐
826 tribute those tasks to the nodes with tasks one and two
827 on the first node, task three on the second node, and
828 task four on the third node. Block distribution is the
829 default behavior if the number of tasks exceeds the num‐
830 ber of allocated nodes.
831 cyclic The cyclic distribution method will distribute tasks to a
833 node such that consecutive tasks are distributed over
834 consecutive nodes (in a round-robin fashion). For exam‐
835 ple, consider an allocation of three nodes each with two
836 cpus. A four-task cyclic distribution request will dis‐
837 tribute those tasks to the nodes with tasks one and four
838 on the first node, task two on the second node, and task
839 three on the third node. Note that when SelectType is
840 select/cons_res, the same number of CPUs may not be allo‐
841 cated on each node. Task distribution will be round-robin
842 among all the nodes with CPUs yet to be assigned to
843 tasks. Cyclic distribution is the default behavior if
844 the number of tasks is no larger than the number of allo‐
845 cated nodes.
846 plane The tasks are distributed in blocks of a specified size.
848 The options include a number representing the size of the
849 task block. This is followed by an optional specifica‐
850 tion of the task distribution scheme within a block of
851 tasks and between the blocks of tasks. The number of
852 tasks distributed to each node is the same as for cyclic
853 distribution, but the taskids assigned to each node
854 depend on the plane size. For more details (including
855 examples and diagrams), please see
856 https://slurm.schedmd.com/mc_support.html
857 and
858 https://slurm.schedmd.com/dist_plane.html
859 arbitrary
861 The arbitrary method of distribution will allocate pro‐
862 cesses in-order as listed in file designated by the envi‐
863 ronment variable SLURM_HOSTFILE. If this variable is
864 listed it will over ride any other method specified. If
865 not set the method will default to block. Inside the
866 hostfile must contain at minimum the number of hosts
867 requested and be one per line or comma separated. If
868 specifying a task count (-n, --ntasks=<number>), your
869 tasks will be laid out on the nodes in the order of the
870 file.
871 NOTE: The arbitrary distribution option on a job alloca‐
872 tion only controls the nodes to be allocated to the job
873 and not the allocation of CPUs on those nodes. This
874 option is meant primarily to control a job step's task
875 layout in an existing job allocation for the srun com‐
876 mand.
877 Second distribution method:
880 block The block distribution method will distribute tasks to
882 sockets such that consecutive tasks share a socket.
883 cyclic The cyclic distribution method will distribute tasks to
885 sockets such that consecutive tasks are distributed over
886 consecutive sockets (in a round-robin fashion). Tasks
887 requiring more than one CPU will have all of those CPUs
888 allocated on a single socket if possible.
889 fcyclic
891 The fcyclic distribution method will distribute tasks to
892 sockets such that consecutive tasks are distributed over
893 consecutive sockets (in a round-robin fashion). Tasks
894 requiring more than one CPU will have each CPUs allocated
895 in a cyclic fashion across sockets.
896 --mail-type=<type>
899 Notify user by email when certain event types occur. Valid type
900 values are NONE, BEGIN, END, FAIL, REQUEUE, ALL (equivalent to
901 BEGIN, END, FAIL, REQUEUE, and STAGE_OUT), STAGE_OUT (burst buf‐
902 fer stage out and teardown completed), TIME_LIMIT, TIME_LIMIT_90
903 (reached 90 percent of time limit), TIME_LIMIT_80 (reached 80
904 percent of time limit), and TIME_LIMIT_50 (reached 50 percent of
905 time limit). Multiple type values may be specified in a comma
906 separated list. The user to be notified is indicated with
907 --mail-user.
908 --mail-user=<user>
911 User to receive email notification of state changes as defined
912 by --mail-type. The default value is the submitting user.
913 --mcs-label=<mcs>
916 Used only when the mcs/group plugin is enabled. This parameter
917 is a group among the groups of the user. Default value is cal‐
918 culated by the Plugin mcs if it's enabled.
919 --mem=<size[units]>
922 Specify the real memory required per node. Default units are
923 megabytes unless the SchedulerParameters configuration parameter
924 includes the "default_gbytes" option for gigabytes. Different
925 units can be specified using the suffix [K|M|G|T]. Default
926 value is DefMemPerNode and the maximum value is MaxMemPerNode.
927 If configured, both of parameters can be seen using the scontrol
928 show config command. This parameter would generally be used if
929 whole nodes are allocated to jobs (SelectType=select/linear).
930 Also see --mem-per-cpu and --mem-per-gpu. The --mem,
931 --mem-per-cpu and --mem-per-gpu options are mutually exclusive.
932 If --mem, --mem-per-cpu or --mem-per-gpu are specified as com‐
933 mand line arguments, then they will take precedence over the
934 environment.
935 NOTE: A memory size specification of zero is treated as a spe‐
937 cial case and grants the job access to all of the memory on each
938 node. If the job is allocated multiple nodes in a heterogeneous
939 cluster, the memory limit on each node will be that of the node
940 in the allocation with the smallest memory size (same limit will
941 apply to every node in the job's allocation).
942 NOTE: Enforcement of memory limits currently relies upon the
944 task/cgroup plugin or enabling of accounting, which samples mem‐
945 ory use on a periodic basis (data need not be stored, just col‐
946 lected). In both cases memory use is based upon the job's Resi‐
947 dent Set Size (RSS). A task may exceed the memory limit until
948 the next periodic accounting sample.
949 --mem-per-cpu=<size[units]>
952 Minimum memory required per allocated CPU. Default units are
953 megabytes unless the SchedulerParameters configuration parameter
954 includes the "default_gbytes" option for gigabytes. Different
955 units can be specified using the suffix [K|M|G|T]. Default
956 value is DefMemPerCPU and the maximum value is MaxMemPerCPU (see
957 exception below). If configured, both of parameters can be seen
958 using the scontrol show config command. Note that if the job's
959 --mem-per-cpu value exceeds the configured MaxMemPerCPU, then
960 the user's limit will be treated as a memory limit per task;
961 --mem-per-cpu will be reduced to a value no larger than MaxMem‐
962 PerCPU; --cpus-per-task will be set and the value of
963 --cpus-per-task multiplied by the new --mem-per-cpu value will
964 equal the original --mem-per-cpu value specified by the user.
965 This parameter would generally be used if individual processors
966 are allocated to jobs (SelectType=select/cons_res). If
967 resources are allocated by the core, socket or whole nodes; the
968 number of CPUs allocated to a job may be higher than the task
969 count and the value of --mem-per-cpu should be adjusted accord‐
970 ingly. Also see --mem and --mem-per-gpu. The --mem,
971 --mem-per-cpu and --mem-per-gpu options are mutually exclusive.
972 NOTE:If the final amount of memory requested by job (eg.: when
974 --mem-per-cpu use with --exclusive option) can't be satisfied by
975 any of nodes configured in the partition, the job will be
976 rejected.
977 --mem-per-gpu=<size[units]>
980 Minimum memory required per allocated GPU. Default units are
981 megabytes unless the SchedulerParameters configuration parameter
982 includes the "default_gbytes" option for gigabytes. Different
983 units can be specified using the suffix [K|M|G|T]. Default
984 value is DefMemPerGPU and is available on both a global and per
985 partition basis. If configured, the parameters can be seen
986 using the scontrol show config and scontrol show partition com‐
987 mands. Also see --mem. The --mem, --mem-per-cpu and
988 --mem-per-gpu options are mutually exclusive.
989 --mem-bind=[{quiet,verbose},]type
992 Bind tasks to memory. Used only when the task/affinity plugin is
993 enabled and the NUMA memory functions are available. Note that
994 the resolution of CPU and memory binding may differ on some
995 architectures. For example, CPU binding may be performed at the
996 level of the cores within a processor while memory binding will
997 be performed at the level of nodes, where the definition of
998 "nodes" may differ from system to system. By default no memory
999 binding is performed; any task using any CPU can use any memory.
1000 This option is typically used to ensure that each task is bound
1001 to the memory closest to it's assigned CPU. The use of any type
1002 other than "none" or "local" is not recommended. If you want
1003 greater control, try running a simple test code with the options
1004 "--cpu-bind=verbose,none --mem-bind=verbose,none" to determine
1005 the specific configuration.
1006 NOTE: To have Slurm always report on the selected memory binding
1008 for all commands executed in a shell, you can enable verbose
1009 mode by setting the SLURM_MEM_BIND environment variable value to
1010 "verbose".
1011 The following informational environment variables are set when
1013 --mem-bind is in use:
1014 SLURM_MEM_BIND_LIST
1016 SLURM_MEM_BIND_PREFER
1017 SLURM_MEM_BIND_SORT
1018 SLURM_MEM_BIND_TYPE
1019 SLURM_MEM_BIND_VERBOSE
1020 See the ENVIRONMENT VARIABLES section for a more detailed
1022 description of the individual SLURM_MEM_BIND* variables.
1023 Supported options include:
1025 help show this help message
1027 local Use memory local to the processor in use
1029 map_mem:<list>
1031 Bind by setting memory masks on tasks (or ranks) as spec‐
1032 ified where <list> is
1033 <numa_id_for_task_0>,<numa_id_for_task_1>,... The map‐
1034 ping is specified for a node and identical mapping is
1035 applied to the tasks on every node (i.e. the lowest task
1036 ID on each node is mapped to the first ID specified in
1037 the list, etc.). NUMA IDs are interpreted as decimal
1038 values unless they are preceded with '0x' in which case
1039 they interpreted as hexadecimal values. If the number of
1040 tasks (or ranks) exceeds the number of elements in this
1041 list, elements in the list will be reused as needed
1042 starting from the beginning of the list. To simplify
1043 support for large task counts, the lists may follow a map
1044 with an asterisk and repetition count For example
1045 "map_mem:0x0f*4,0xf0*4". Not supported unless the entire
1046 node is allocated to the job.
1047 mask_mem:<list>
1049 Bind by setting memory masks on tasks (or ranks) as spec‐
1050 ified where <list> is
1051 <numa_mask_for_task_0>,<numa_mask_for_task_1>,... The
1052 mapping is specified for a node and identical mapping is
1053 applied to the tasks on every node (i.e. the lowest task
1054 ID on each node is mapped to the first mask specified in
1055 the list, etc.). NUMA masks are always interpreted as
1056 hexadecimal values. Note that masks must be preceded
1057 with a '0x' if they don't begin with [0-9] so they are
1058 seen as numerical values. If the number of tasks (or
1059 ranks) exceeds the number of elements in this list, ele‐
1060 ments in the list will be reused as needed starting from
1061 the beginning of the list. To simplify support for large
1062 task counts, the lists may follow a mask with an asterisk
1063 and repetition count For example "mask_mem:0*4,1*4". Not
1064 supported unless the entire node is allocated to the job.
1065 no[ne] don't bind tasks to memory (default)
1067 p[refer]
1069 Prefer use of first specified NUMA node, but permit
1070 use of other available NUMA nodes.
1071 q[uiet]
1073 quietly bind before task runs (default)
1074 rank bind by task rank (not recommended)
1076 sort sort free cache pages (run zonesort on Intel KNL nodes)
1078 v[erbose]
1080 verbosely report binding before task runs
1081 --mincpus=<n>
1084 Specify a minimum number of logical cpus/processors per node.
1085 -N, --nodes=<minnodes[-maxnodes]>
1088 Request that a minimum of minnodes nodes be allocated to this
1089 job. A maximum node count may also be specified with maxnodes.
1090 If only one number is specified, this is used as both the mini‐
1091 mum and maximum node count. The partition's node limits super‐
1092 sede those of the job. If a job's node limits are outside of
1093 the range permitted for its associated partition, the job will
1094 be left in a PENDING state. This permits possible execution at
1095 a later time, when the partition limit is changed. If a job
1096 node limit exceeds the number of nodes configured in the parti‐
1097 tion, the job will be rejected. Note that the environment vari‐
1098 able SLURM_JOB_NODES will be set to the count of nodes actually
1099 allocated to the job. See the ENVIRONMENT VARIABLES section for
1100 more information. If -N is not specified, the default behavior
1101 is to allocate enough nodes to satisfy the requirements of the
1102 -n and -c options. The job will be allocated as many nodes as
1103 possible within the range specified and without delaying the
1104 initiation of the job. The node count specification may include
1105 a numeric value followed by a suffix of "k" (multiplies numeric
1106 value by 1,024) or "m" (multiplies numeric value by 1,048,576).
1107 -n, --ntasks=<number>
1110 salloc does not launch tasks, it requests an allocation of
1111 resources and executed some command. This option advises the
1112 Slurm controller that job steps run within this allocation will
1113 launch a maximum of number tasks and sufficient resources are
1114 allocated to accomplish this. The default is one task per node,
1115 but note that the --cpus-per-task option will change this
1116 default.
1117 --network=<type>
1120 Specify information pertaining to the switch or network. The
1121 interpretation of type is system dependent. This option is sup‐
1122 ported when running Slurm on a Cray natively. It is used to
1123 request using Network Performance Counters. Only one value per
1124 request is valid. All options are case in-sensitive. In this
1125 configuration supported values include:
1126 system
1128 Use the system-wide network performance counters. Only
1129 nodes requested will be marked in use for the job alloca‐
1130 tion. If the job does not fill up the entire system the
1131 rest of the nodes are not able to be used by other jobs
1132 using NPC, if idle their state will appear as PerfCnts.
1133 These nodes are still available for other jobs not using
1134 NPC.
1135 blade Use the blade network performance counters. Only nodes
1137 requested will be marked in use for the job allocation.
1138 If the job does not fill up the entire blade(s) allocated
1139 to the job those blade(s) are not able to be used by other
1140 jobs using NPC, if idle their state will appear as PerfC‐
1141 nts. These nodes are still available for other jobs not
1142 using NPC.
1143 In all cases the job allocation request must specify the
1146 --exclusive option. Otherwise the request will be denied.
1147 Also with any of these options steps are not allowed to share
1149 blades, so resources would remain idle inside an allocation if
1150 the step running on a blade does not take up all the nodes on
1151 the blade.
1152 The network option is also supported on systems with IBM's Par‐
1154 allel Environment (PE). See IBM's LoadLeveler job command key‐
1155 word documentation about the keyword "network" for more informa‐
1156 tion. Multiple values may be specified in a comma separated
1157 list. All options are case in-sensitive. Supported values
1158 include:
1159 BULK_XFER[=<resources>]
1161 Enable bulk transfer of data using Remote Direct-
1162 Memory Access (RDMA). The optional resources speci‐
1163 fication is a numeric value which can have a suffix
1164 of "k", "K", "m", "M", "g" or "G" for kilobytes,
1165 megabytes or gigabytes. NOTE: The resources speci‐
1166 fication is not supported by the underlying IBM in‐
1167 frastructure as of Parallel Environment version 2.2
1168 and no value should be specified at this time.
1169 CAU=<count> Number of Collectve Acceleration Units (CAU)
1171 required. Applies only to IBM Power7-IH processors.
1172 Default value is zero. Independent CAU will be
1173 allocated for each programming interface (MPI, LAPI,
1174 etc.)
1175 DEVNAME=<name>
1177 Specify the device name to use for communications
1178 (e.g. "eth0" or "mlx4_0").
1179 DEVTYPE=<type>
1181 Specify the device type to use for communications.
1182 The supported values of type are: "IB" (InfiniBand),
1183 "HFI" (P7 Host Fabric Interface), "IPONLY" (IP-Only
1184 interfaces), "HPCE" (HPC Ethernet), and "KMUX" (Ker‐
1185 nel Emulation of HPCE). The devices allocated to a
1186 job must all be of the same type. The default value
1187 depends upon depends upon what hardware is available
1188 and in order of preferences is IPONLY (which is not
1189 considered in User Space mode), HFI, IB, HPCE, and
1190 KMUX.
1191 IMMED =<count>
1193 Number of immediate send slots per window required.
1194 Applies only to IBM Power7-IH processors. Default
1195 value is zero.
1196 INSTANCES =<count>
1198 Specify number of network connections for each task
1199 on each network connection. The default instance
1200 count is 1.
1201 IPV4 Use Internet Protocol (IP) version 4 communications
1203 (default).
1204 IPV6 Use Internet Protocol (IP) version 6 communications.
1206 LAPI Use the LAPI programming interface.
1208 MPI Use the MPI programming interface. MPI is the
1210 default interface.
1211 PAMI Use the PAMI programming interface.
1213 SHMEM Use the OpenSHMEM programming interface.
1215 SN_ALL Use all available switch networks (default).
1217 SN_SINGLE Use one available switch network.
1219 UPC Use the UPC programming interface.
1221 US Use User Space communications.
1223 Some examples of network specifications:
1226 Instances=2,US,MPI,SN_ALL
1228 Create two user space connections for MPI communica‐
1229 tions on every switch network for each task.
1230 US,MPI,Instances=3,Devtype=IB
1232 Create three user space connections for MPI communi‐
1233 cations on every InfiniBand network for each task.
1234 IPV4,LAPI,SN_Single
1236 Create a IP version 4 connection for LAPI communica‐
1237 tions on one switch network for each task.
1238 Instances=2,US,LAPI,MPI
1240 Create two user space connections each for LAPI and
1241 MPI communications on every switch network for each
1242 task. Note that SN_ALL is the default option so
1243 every switch network is used. Also note that
1244 Instances=2 specifies that two connections are
1245 established for each protocol (LAPI and MPI) and
1246 each task. If there are two networks and four tasks
1247 on the node then a total of 32 connections are
1248 established (2 instances x 2 protocols x 2 networks
1249 x 4 tasks).
1250 --nice[=adjustment]
1253 Run the job with an adjusted scheduling priority within Slurm.
1254 With no adjustment value the scheduling priority is decreased by
1255 100. A negative nice value increases the priority, otherwise
1256 decreases it. The adjustment range is +/- 2147483645. Only priv‐
1257 ileged users can specify a negative adjustment.
1258 --ntasks-per-core=<ntasks>
1261 Request the maximum ntasks be invoked on each core. Meant to be
1262 used with the --ntasks option. Related to --ntasks-per-node
1263 except at the core level instead of the node level. NOTE: This
1264 option is not supported unless SelectType=cons_res is configured
1265 (either directly or indirectly on Cray systems) along with the
1266 node's core count.
1267 --ntasks-per-node=<ntasks>
1270 Request that ntasks be invoked on each node. If used with the
1271 --ntasks option, the --ntasks option will take precedence and
1272 the --ntasks-per-node will be treated as a maximum count of
1273 tasks per node. Meant to be used with the --nodes option. This
1274 is related to --cpus-per-task=ncpus, but does not require knowl‐
1275 edge of the actual number of cpus on each node. In some cases,
1276 it is more convenient to be able to request that no more than a
1277 specific number of tasks be invoked on each node. Examples of
1278 this include submitting a hybrid MPI/OpenMP app where only one
1279 MPI "task/rank" should be assigned to each node while allowing
1280 the OpenMP portion to utilize all of the parallelism present in
1281 the node, or submitting a single setup/cleanup/monitoring job to
1282 each node of a pre-existing allocation as one step in a larger
1283 job script.
1284 --ntasks-per-socket=<ntasks>
1287 Request the maximum ntasks be invoked on each socket. Meant to
1288 be used with the --ntasks option. Related to --ntasks-per-node
1289 except at the socket level instead of the node level. NOTE:
1290 This option is not supported unless SelectType=cons_res is con‐
1291 figured (either directly or indirectly on Cray systems) along
1292 with the node's socket count.
1293 --no-bell
1296 Silence salloc's use of the terminal bell. Also see the option
1297 --bell.
1298 --no-shell
1301 immediately exit after allocating resources, without running a
1302 command. However, the Slurm job will still be created and will
1303 remain active and will own the allocated resources as long as it
1304 is active. You will have a Slurm job id with no associated pro‐
1305 cesses or tasks. You can submit srun commands against this
1306 resource allocation, if you specify the --jobid= option with the
1307 job id of this Slurm job. Or, this can be used to temporarily
1308 reserve a set of resources so that other jobs cannot use them
1309 for some period of time. (Note that the Slurm job is subject to
1310 the normal constraints on jobs, including time limits, so that
1311 eventually the job will terminate and the resources will be
1312 freed, or you can terminate the job manually using the scancel
1313 command.)
1314 -O, --overcommit
1317 Overcommit resources. When applied to job allocation, only one
1318 CPU is allocated to the job per node and options used to specify
1319 the number of tasks per node, socket, core, etc. are ignored.
1320 When applied to job step allocations (the srun command when exe‐
1321 cuted within an existing job allocation), this option can be
1322 used to launch more than one task per CPU. Normally, srun will
1323 not allocate more than one process per CPU. By specifying
1324 --overcommit you are explicitly allowing more than one process
1325 per CPU. However no more than MAX_TASKS_PER_NODE tasks are per‐
1326 mitted to execute per node. NOTE: MAX_TASKS_PER_NODE is defined
1327 in the file slurm.h and is not a variable, it is set at Slurm
1328 build time.
1329 -p, --partition=<partition_names>
1332 Request a specific partition for the resource allocation. If
1333 not specified, the default behavior is to allow the slurm con‐
1334 troller to select the default partition as designated by the
1335 system administrator. If the job can use more than one parti‐
1336 tion, specify their names in a comma separate list and the one
1337 offering earliest initiation will be used with no regard given
1338 to the partition name ordering (although higher priority parti‐
1339 tions will be considered first). When the job is initiated, the
1340 name of the partition used will be placed first in the job
1341 record partition string.
1342 --power=<flags>
1345 Comma separated list of power management plugin options. Cur‐
1346 rently available flags include: level (all nodes allocated to
1347 the job should have identical power caps, may be disabled by the
1348 Slurm configuration option PowerParameters=job_no_level).
1349 --priority=<value>
1352 Request a specific job priority. May be subject to configura‐
1353 tion specific constraints. value should either be a numeric
1354 value or "TOP" (for highest possible value). Only Slurm opera‐
1355 tors and administrators can set the priority of a job.
1356 --profile=<all|none|[energy[,|task[,|lustre[,|network]]]]>
1359 enables detailed data collection by the acct_gather_profile
1360 plugin. Detailed data are typically time-series that are stored
1361 in an HDF5 file for the job or an InfluxDB database depending on
1362 the configured plugin.
1363 All All data types are collected. (Cannot be combined with
1366 other values.)
1367 None No data types are collected. This is the default.
1370 (Cannot be combined with other values.)
1371 Energy Energy data is collected.
1374 Task Task (I/O, Memory, ...) data is collected.
1377 Lustre Lustre data is collected.
1380 Network Network (InfiniBand) data is collected.
1383 -q, --qos=<qos>
1386 Request a quality of service for the job. QOS values can be
1387 defined for each user/cluster/account association in the Slurm
1388 database. Users will be limited to their association's defined
1389 set of qos's when the Slurm configuration parameter, Account‐
1390 ingStorageEnforce, includes "qos" in it's definition.
1391 -Q, --quiet
1394 Suppress informational messages from salloc. Errors will still
1395 be displayed.
1396 --reboot
1399 Force the allocated nodes to reboot before starting the job.
1400 This is only supported with some system configurations and will
1401 otherwise be silently ignored.
1402 --reservation=<name>
1405 Allocate resources for the job from the named reservation.
1406 -s, --oversubscribe
1409 The job allocation can over-subscribe resources with other run‐
1410 ning jobs. The resources to be over-subscribed can be nodes,
1411 sockets, cores, and/or hyperthreads depending upon configura‐
1412 tion. The default over-subscribe behavior depends on system
1413 configuration and the partition's OverSubscribe option takes
1414 precedence over the job's option. This option may result in the
1415 allocation being granted sooner than if the --oversubscribe
1416 option was not set and allow higher system utilization, but
1417 application performance will likely suffer due to competition
1418 for resources. Also see the --exclusive option.
1419 -S, --core-spec=<num>
1422 Count of specialized cores per node reserved by the job for sys‐
1423 tem operations and not used by the application. The application
1424 will not use these cores, but will be charged for their alloca‐
1425 tion. Default value is dependent upon the node's configured
1426 CoreSpecCount value. If a value of zero is designated and the
1427 Slurm configuration option AllowSpecResourcesUsage is enabled,
1428 the job will be allowed to override CoreSpecCount and use the
1429 specialized resources on nodes it is allocated. This option can
1430 not be used with the --thread-spec option.
1431 --signal=<sig_num>[@<sig_time>]
1434 When a job is within sig_time seconds of its end time, send it
1435 the signal sig_num. Due to the resolution of event handling by
1436 Slurm, the signal may be sent up to 60 seconds earlier than
1437 specified. sig_num may either be a signal number or name (e.g.
1438 "10" or "USR1"). sig_time must have an integer value between 0
1439 and 65535. By default, no signal is sent before the job's end
1440 time. If a sig_num is specified without any sig_time, the
1441 default time will be 60 seconds. To have the signal sent at
1442 preemption time see the preempt_send_user_signal SlurmctldParam‐
1443 eter.
1444 --sockets-per-node=<sockets>
1447 Restrict node selection to nodes with at least the specified
1448 number of sockets. See additional information under -B option
1449 above when task/affinity plugin is enabled.
1450 --spread-job
1453 Spread the job allocation over as many nodes as possible and
1454 attempt to evenly distribute tasks across the allocated nodes.
1455 This option disables the topology/tree plugin.
1456 --switches=<count>[@<max-time>]
1459 When a tree topology is used, this defines the maximum count of
1460 switches desired for the job allocation and optionally the maxi‐
1461 mum time to wait for that number of switches. If Slurm finds an
1462 allocation containing more switches than the count specified,
1463 the job remains pending until it either finds an allocation with
1464 desired switch count or the time limit expires. It there is no
1465 switch count limit, there is no delay in starting the job.
1466 Acceptable time formats include "minutes", "minutes:seconds",
1467 "hours:minutes:seconds", "days-hours", "days-hours:minutes" and
1468 "days-hours:minutes:seconds". The job's maximum time delay may
1469 be limited by the system administrator using the SchedulerParam‐
1470 eters configuration parameter with the max_switch_wait parameter
1471 option. On a dragonfly network the only switch count supported
1472 is 1 since communication performance will be highest when a job
1473 is allocate resources on one leaf switch or more than 2 leaf
1474 switches. The default max-time is the max_switch_wait Sched‐
1475 ulerParameters.
1476 -t, --time=<time>
1479 Set a limit on the total run time of the job allocation. If the
1480 requested time limit exceeds the partition's time limit, the job
1481 will be left in a PENDING state (possibly indefinitely). The
1482 default time limit is the partition's default time limit. When
1483 the time limit is reached, each task in each job step is sent
1484 SIGTERM followed by SIGKILL. The interval between signals is
1485 specified by the Slurm configuration parameter KillWait. The
1486 OverTimeLimit configuration parameter may permit the job to run
1487 longer than scheduled. Time resolution is one minute and second
1488 values are rounded up to the next minute.
1489 A time limit of zero requests that no time limit be imposed.
1491 Acceptable time formats include "minutes", "minutes:seconds",
1492 "hours:minutes:seconds", "days-hours", "days-hours:minutes" and
1493 "days-hours:minutes:seconds".
1494 --thread-spec=<num>
1497 Count of specialized threads per node reserved by the job for
1498 system operations and not used by the application. The applica‐
1499 tion will not use these threads, but will be charged for their
1500 allocation. This option can not be used with the --core-spec
1501 option.
1502 --threads-per-core=<threads>
1505 Restrict node selection to nodes with at least the specified
1506 number of threads per core. NOTE: "Threads" refers to the num‐
1507 ber of processing units on each core rather than the number of
1508 application tasks to be launched per core. See additional
1509 information under -B option above when task/affinity plugin is
1510 enabled.
1511 --time-min=<time>
1514 Set a minimum time limit on the job allocation. If specified,
1515 the job may have it's --time limit lowered to a value no lower
1516 than --time-min if doing so permits the job to begin execution
1517 earlier than otherwise possible. The job's time limit will not
1518 be changed after the job is allocated resources. This is per‐
1519 formed by a backfill scheduling algorithm to allocate resources
1520 otherwise reserved for higher priority jobs. Acceptable time
1521 formats include "minutes", "minutes:seconds", "hours:min‐
1522 utes:seconds", "days-hours", "days-hours:minutes" and
1523 "days-hours:minutes:seconds".
1524 --tmp=<size[units]>
1527 Specify a minimum amount of temporary disk space per node.
1528 Default units are megabytes unless the SchedulerParameters con‐
1529 figuration parameter includes the "default_gbytes" option for
1530 gigabytes. Different units can be specified using the suffix
1531 [K|M|G|T].
1532 --usage
1535 Display brief help message and exit.
1536 --uid=<user>
1539 Attempt to submit and/or run a job as user instead of the invok‐
1540 ing user id. The invoking user's credentials will be used to
1541 check access permissions for the target partition. This option
1542 is only valid for user root. This option may be used by user
1543 root may use this option to run jobs as a normal user in a
1544 RootOnly partition for example. If run as root, salloc will drop
1545 its permissions to the uid specified after node allocation is
1546 successful. user may be the user name or numerical user ID.
1547 --use-min-nodes
1550 If a range of node counts is given, prefer the smaller count.
1551 -V, --version
1554 Display version information and exit.
1555 -v, --verbose
1558 Increase the verbosity of salloc's informational messages. Mul‐
1559 tiple -v's will further increase salloc's verbosity. By default
1560 only errors will be displayed.
1561 -w, --nodelist=<node name list>
1564 Request a specific list of hosts. The job will contain all of
1565 these hosts and possibly additional hosts as needed to satisfy
1566 resource requirements. The list may be specified as a
1567 comma-separated list of hosts, a range of hosts (host[1-5,7,...]
1568 for example), or a filename. The host list will be assumed to
1569 be a filename if it contains a "/" character. If you specify a
1570 minimum node or processor count larger than can be satisfied by
1571 the supplied host list, additional resources will be allocated
1572 on other nodes as needed. Duplicate node names in the list will
1573 be ignored. The order of the node names in the list is not
1574 important; the node names will be sorted by Slurm.
1575 --wait-all-nodes=<value>
1578 Controls when the execution of the command begins with respect
1579 to when nodes are ready for use (i.e. booted). By default, the
1580 salloc command will return as soon as the allocation is made.
1581 This default can be altered using the salloc_wait_nodes option
1582 to the SchedulerParameters parameter in the slurm.conf file.
1583 0 Begin execution as soon as allocation can be made. Do not
1585 wait for all nodes to be ready for use (i.e. booted).
1586 1 Do not begin execution until all nodes are ready for use.
1588 --wckey=<wckey>
1591 Specify wckey to be used with job. If TrackWCKey=no (default)
1592 in the slurm.conf this value is ignored.
1593 -x, --exclude=<node name list>
1596 Explicitly exclude certain nodes from the resources granted to
1597 the job.
1598 --x11[=<all|first|last>]
1601 Sets up X11 forwarding on all, first or last node(s) of the
1602 allocation. This option is only enabled if Slurm was compiled
1603 with X11 support and PrologFlags=x11 is defined in the
1604 slurm.conf. Default is all.
1605
1608 Upon startup, salloc will read and handle the options set in the fol‐
1609 lowing environment variables. Note: Command line options always over‐
1610 ride environment variables settings.
1611 SALLOC_ACCOUNT Same as -A, --account
1614 SALLOC_ACCTG_FREQ Same as --acctg-freq
1616 SALLOC_BELL Same as --bell
1618 SALLOC_BURST_BUFFER Same as --bb
1620 SALLOC_CLUSTERS or SLURM_CLUSTERS
1622 Same as --clusters
1623 SALLOC_CONSTRAINT Same as -C, --constraint
1625 SALLOC_CORE_SPEC Same as --core-spec
1627 SALLOC_CPUS_PER_GPU Same as --cpus-per-gpu
1629 SALLOC_DEBUG Same as -v, --verbose
1631 SALLOC_DELAY_BOOT Same as --delay-boot
1633 SALLOC_EXCLUSIVE Same as --exclusive
1635 SALLOC_GPUS Same as -G, --gpus
1637 SALLOC_GPU_BIND Same as --gpu-bind
1639 SALLOC_GPU_FREQ Same as --gpu-freq
1641 SALLOC_GPUS_PER_NODE Same as --gpus-per-node
1643 SALLOC_GPUS_PER_TASK Same as --gpus-per-task SALLOC_GRES Same as
1645 --gres
1646 SALLOC_GRES_FLAGS Same as --gres-flags
1648 SALLOC_HINT or SLURM_HINT
1650 Same as --hint
1651 SALLOC_IMMEDIATE Same as -I, --immediate
1653 SALLOC_KILL_CMD Same as -K, --kill-command
1655 SALLOC_MEM_BIND Same as --mem-bind
1657 SALLOC_MEM_PER_GPU Same as --mem-per-gpu
1659 SALLOC_NETWORK Same as --network
1661 SALLOC_NO_BELL Same as --no-bell
1663 SALLOC_NO_KILL Same as -k, --no-kill
1665 SALLOC_OVERCOMMIT Same as -O, --overcommit
1667 SALLOC_PARTITION Same as -p, --partition
1669 SALLOC_POWER Same as --power
1671 SALLOC_PROFILE Same as --profile
1673 SALLOC_QOS Same as --qos
1675 SALLOC_REQ_SWITCH When a tree topology is used, this defines the
1677 maximum count of switches desired for the job
1678 allocation and optionally the maximum time to
1679 wait for that number of switches. See --switches.
1680 SALLOC_RESERVATION Same as --reservation
1682 SALLOC_SIGNAL Same as --signal
1684 SALLOC_SPREAD_JOB Same as --spread-job
1686 SALLOC_THREAD_SPEC Same as --thread-spec
1688 SALLOC_TIMELIMIT Same as -t, --time
1690 SALLOC_USE_MIN_NODES Same as --use-min-nodes
1692 SALLOC_WAIT_ALL_NODES Same as --wait-all-nodes
1694 SALLOC_WCKEY Same as --wckey
1696 SALLOC_WAIT4SWITCH Max time waiting for requested switches. See
1698 --switches
1699 SLURM_CONF The location of the Slurm configuration file.
1701 SLURM_EXIT_ERROR Specifies the exit code generated when a Slurm
1703 error occurs (e.g. invalid options). This can be
1704 used by a script to distinguish application exit
1705 codes from various Slurm error conditions. Also
1706 see SLURM_EXIT_IMMEDIATE.
1707 SLURM_EXIT_IMMEDIATE Specifies the exit code generated when the
1709 --immediate option is used and resources are not
1710 currently available. This can be used by a
1711 script to distinguish application exit codes from
1712 various Slurm error conditions. Also see
1713 SLURM_EXIT_ERROR.
1714
1717 salloc will set the following environment variables in the environment
1718 of the executed program:
1719 SLURM_*_PACK_GROUP_#
1721 For a heterogeneous job allocation, the environment variables
1722 are set separately for each component.
1723 SLURM_CLUSTER_NAME
1725 Name of the cluster on which the job is executing.
1726 SLURM_CPUS_PER_GPU
1728 Number of CPUs requested per allocated GPU. Only set if the
1729 --cpus-per-gpu option is specified.
1730 SLURM_CPUS_PER_TASK
1732 Number of CPUs requested per task. Only set if the
1733 --cpus-per-task option is specified.
1734 SLURM_DISTRIBUTION
1736 Only set if the -m, --distribution option is specified.
1737 SLURM_GPUS
1739 Number of GPUs requested. Only set if the -G, --gpus option is
1740 specified.
1741 SLURM_GPU_BIND
1743 Requested binding of tasks to GPU. Only set if the --gpu-bind
1744 option is specified.
1745 SLURM_GPU_FREQ
1747 Requested GPU frequency. Only set if the --gpu-freq option is
1748 specified.
1749 SLURM_GPUS_PER_NODE
1751 Requested GPU count per allocated node. Only set if the
1752 --gpus-per-node option is specified.
1753 SLURM_GPUS_PER_SOCKET
1755 Requested GPU count per allocated socket. Only set if the
1756 --gpus-per-socket option is specified.
1757 SLURM_GPUS_PER_TASK
1759 Requested GPU count per allocated task. Only set if the
1760 --gpus-per-task option is specified.
1761 SLURM_JOB_ACCOUNT
1763 Account name associated of the job allocation.
1764 SLURM_JOB_ID (and SLURM_JOBID for backwards compatibility)
1766 The ID of the job allocation.
1767 SLURM_JOB_CPUS_PER_NODE
1769 Count of processors available to the job on this node. Note the
1770 select/linear plugin allocates entire nodes to jobs, so the
1771 value indicates the total count of CPUs on each node. The
1772 select/cons_res plugin allocates individual processors to jobs,
1773 so this number indicates the number of processors on each node
1774 allocated to the job allocation.
1775 SLURM_JOB_NODELIST (and SLURM_NODELIST for backwards compatibility)
1777 List of nodes allocated to the job.
1778 SLURM_JOB_NUM_NODES (and SLURM_NNODES for backwards compatibility)
1780 Total number of nodes in the job allocation.
1781 SLURM_JOB_PARTITION
1783 Name of the partition in which the job is running.
1784 SLURM_JOB_QOS
1786 Quality Of Service (QOS) of the job allocation.
1787 SLURM_JOB_RESERVATION
1789 Advanced reservation containing the job allocation, if any.
1790 SLURM_MEM_BIND
1792 Set to value of the --mem-bind option.
1793 SLURM_MEM_BIND_LIST
1795 Set to bit mask used for memory binding.
1796 SLURM_MEM_BIND_PREFER
1798 Set to "prefer" if the --mem-bind option includes the prefer
1799 option.
1800 SLURM_MEM_BIND_SORT
1802 Sort free cache pages (run zonesort on Intel KNL nodes)
1803 SLURM_MEM_BIND_TYPE
1805 Set to the memory binding type specified with the --mem-bind
1806 option. Possible values are "none", "rank", "map_map",
1807 "mask_mem" and "local".
1808 SLURM_MEM_BIND_VERBOSE
1810 Set to "verbose" if the --mem-bind option includes the verbose
1811 option. Set to "quiet" otherwise.
1812 SLURM_MEM_PER_CPU
1814 Same as --mem-per-cpu
1815 SLURM_MEM_PER_GPU
1817 Requested memory per allocated GPU. Only set if the
1818 --mem-per-gpu option is specified.
1819 SLURM_MEM_PER_NODE
1821 Same as --mem
1822 SLURM_PACK_SIZE
1824 Set to count of components in heterogeneous job.
1825 SLURM_SUBMIT_DIR
1827 The directory from which salloc was invoked or, if applicable,
1828 the directory specified by the -D, --chdir option.
1829 SLURM_SUBMIT_HOST
1831 The hostname of the computer from which salloc was invoked.
1832 SLURM_NODE_ALIASES
1834 Sets of node name, communication address and hostname for nodes
1835 allocated to the job from the cloud. Each element in the set if
1836 colon separated and each set is comma separated. For example:
1837 SLURM_NODE_ALIASES=ec0:1.2.3.4:foo,ec1:1.2.3.5:bar
1838 SLURM_NTASKS
1840 Same as -n, --ntasks
1841 SLURM_NTASKS_PER_CORE
1843 Set to value of the --ntasks-per-core option, if specified.
1844 SLURM_NTASKS_PER_NODE
1846 Set to value of the --ntasks-per-node option, if specified.
1847 SLURM_NTASKS_PER_SOCKET
1849 Set to value of the --ntasks-per-socket option, if specified.
1850 SLURM_PROFILE
1852 Same as --profile
1853 SLURM_TASKS_PER_NODE
1855 Number of tasks to be initiated on each node. Values are comma
1856 separated and in the same order as SLURM_JOB_NODELIST. If two
1857 or more consecutive nodes are to have the same task count, that
1858 count is followed by "(x#)" where "#" is the repetition count.
1859 For example, "SLURM_TASKS_PER_NODE=2(x3),1" indicates that the
1860 first three nodes will each execute three tasks and the fourth
1861 node will execute one task.
1862
1865 While salloc is waiting for a PENDING job allocation, most signals will
1866 cause salloc to revoke the allocation request and exit.
1867 However if the allocation has been granted and salloc has already
1869 started the specified command, then salloc will ignore most signals.
1870 salloc will not exit or release the allocation until the command exits.
1871 One notable exception is SIGHUP. A SIGHUP signal will cause salloc to
1872 release the allocation and exit without waiting for the command to fin‐
1873 ish. Another exception is SIGTERM, which will be forwarded to the
1874 spawned process.
1875
1878 To get an allocation, and open a new xterm in which srun commands may
1879 be typed interactively:
1880 $ salloc -N16 xterm
1882 salloc: Granted job allocation 65537
1883 (at this point the xterm appears, and salloc waits for xterm to
1884 exit)
1885 salloc: Relinquishing job allocation 65537
1886 To grab an allocation of nodes and launch a parallel application on one
1888 command line (See the salloc man page for more examples):
1889 salloc -N5 srun -n10 myprogram
1891 +To create a heterogeneous job with 3 components, each allocating a
1893 unique set of nodes:
1894 salloc -w node[2-3] : -w node4 : -w node[5-7] bash
1896 salloc: job 32294 queued and waiting for resources
1897 salloc: job 32294 has been allocated resources
1898 salloc: Granted job allocation 32294
1899
1902 Copyright (C) 2006-2007 The Regents of the University of California.
1903 Produced at Lawrence Livermore National Laboratory (cf, DISCLAIMER).
1904 Copyright (C) 2008-2010 Lawrence Livermore National Security.
1905 Copyright (C) 2010-2018 SchedMD LLC.
1906 This file is part of Slurm, a resource management program. For
1908 details, see <https://slurm.schedmd.com/>.
1909 Slurm is free software; you can redistribute it and/or modify it under
1911 the terms of the GNU General Public License as published by the Free
1912 Software Foundation; either version 2 of the License, or (at your
1913 option) any later version.
1914 Slurm is distributed in the hope that it will be useful, but WITHOUT
1916 ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
1917 FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License
1918 for more details.
1919
1922 sinfo(1), sattach(1), sbatch(1), squeue(1), scancel(1), scontrol(1),
1923 slurm.conf(5), sched_setaffinity (2), numa (3)
1924December 2019 Slurm Commands salloc(1)