Hello all,
Thanks for the useful observations. Here is some further env vars:
# non problematic case
$ srun -c 3 --partition=gpu-2080ti env
SRUN_DEBUG=3
SLURM_JOB_CPUS_PER_NODE=4
SLURM_NTASKS=1
SLURM_NPROCS=1
SLURM_CPUS_PER_TASK=3
SLURM_STEP_ID=0
SLURM_STEPID=0
SLURM_NNODES=1
Hi Bjørn-Helge,
that's very similar to what we did as well in order to avoid confusion with
Core vs. Threads vs. CPU counts when Hyperthreading is kept enabled in the
BIOS.
Adding CPUs= (not ) will tell Slurm to only
schedule physical cores.
We have
SelectType=select/cons_res
Hermann Schwärzler writes:
> Do you happen to know if there is a difference between setting CPUs
> explicitely like you do it and not setting it but using
> "ThreadsPerCore=1"?
>
> My guess is that there is no difference and in both cases only the
> physical cores are "handed out to jobs". But
Hi Bjørn-Helge,
hi everone,
ok, I see. I also just re-read the documentation to find this in the
description of the "CPUs" option:
"This can be useful when you want to schedule only the cores on a
hyper-threaded node. If CPUs is omitted, its default will be set equal
to the product of
For what it's worth, we have a similar setup, with one crucial
difference: we are handing out physical cores to jobs, not hyperthreads,
and we are *not* seeing this behaviour:
$ srun --cpus-per-task=1 -t 10 --mem-per-cpu=1g -A nnk -q devel echo foo
srun: job 5371678 queued and waiting for
Hi Durai,
I see the same thing as you on our test-cluster that has
ThreadsPerCore=2
configured in slurm.conf
The double-foo goes away with this:
srun --cpus-per-task=1 --hint=nomultithread echo foo
Having multithreading enabled leads to imho surprising behaviour of
Slurm. My impression is
