diff options
author | Harmen Stoppels <harmenstoppels@gmail.com> | 2021-03-30 21:03:50 +0200 |
---|---|---|
committer | GitHub <noreply@github.com> | 2021-03-30 12:03:50 -0700 |
commit | 1db6cd5d16a084bffbc319467d70942d0307cc9f (patch) | |
tree | 01b65aca7df8c6644e291aad80ea82d4f560ceac /lib/spack/docs/config_yaml.rst | |
parent | d3a9824ea2f7675e9e0008b5d914f02e63e19d85 (diff) | |
download | spack-1db6cd5d16a084bffbc319467d70942d0307cc9f.tar.gz spack-1db6cd5d16a084bffbc319467d70942d0307cc9f.tar.bz2 spack-1db6cd5d16a084bffbc319467d70942d0307cc9f.tar.xz spack-1db6cd5d16a084bffbc319467d70942d0307cc9f.zip |
Make -j flag less exceptional (#22360)
* Make -j flag less exceptional
The -j flag in spack behaves differently from make, ctest, ninja, etc,
because it caps the number of jobs to an arbitrary number 16.
Spack will behave like other tools if `spack install` uses a reasonable
default, and `spack install -j <num>` *overrides* that default.
This will be particularly useful for Spack usage outside of a traditional
HPC context and for HPC centers that encourage users to compile on
login nodes with many cores instead of on compute nodes, which has
become increasingly common as individual nodes have more cores.
This maintains the existing default value of min(num_cpus, 16). However,
as it is right now, Spack does a poor job at determining the number of
cpus on linux, since it doesn't take cgroups into account. This is
particularly problematic when using distributed builds with slurm. This PR
also introduces `spack.util.cpus.cpus_available()` to consolidate
knowledge on determining the number of available cores, and improves
core detection for linux. This should also improve core detection for Docker/
Kubernetes, which also use cgroups.
Diffstat (limited to 'lib/spack/docs/config_yaml.rst')
-rw-r--r-- | lib/spack/docs/config_yaml.rst | 16 |
1 files changed, 9 insertions, 7 deletions
diff --git a/lib/spack/docs/config_yaml.rst b/lib/spack/docs/config_yaml.rst index 66df916193..631b8f6b1b 100644 --- a/lib/spack/docs/config_yaml.rst +++ b/lib/spack/docs/config_yaml.rst @@ -202,21 +202,23 @@ of builds. Unless overridden in a package or on the command line, Spack builds all packages in parallel. The default parallelism is equal to the number of -cores on your machine, up to 16. Parallelism cannot exceed the number of -cores available on the host. For a build system that uses Makefiles, this -means running: +cores available to the process, up to 16 (the default of ``build_jobs``). +For a build system that uses Makefiles, this ``spack install`` runs: - ``make -j<build_jobs>``, when ``build_jobs`` is less than the number of - cores on the machine + cores available - ``make -j<ncores>``, when ``build_jobs`` is greater or equal to the - number of cores on the machine + number of cores available If you work on a shared login node or have a strict ulimit, it may be necessary to set the default to a lower value. By setting ``build_jobs`` to 4, for example, commands like ``spack install`` will run ``make -j4`` -instead of hogging every core. +instead of hogging every core. To build all software in serial, +set ``build_jobs`` to 1. -To build all software in serial, set ``build_jobs`` to 1. +Note that specifying the number of jobs on the command line always takes +priority, so that ``spack install -j<n>`` always runs `make -j<n>`, even +when that exceeds the number of cores available. -------------------- ``ccache`` |