- 18 Jun, 2015 4 commits
-
-
Danny Auble authored
enum.
-
Danny Auble authored
-
Danny Auble authored
-
Danny Auble authored
first.
-
- 17 Jun, 2015 3 commits
-
-
Danny Auble authored
-
Danny Auble authored
-
Danny Auble authored
instead of 3 different options
-
- 16 Jun, 2015 9 commits
-
-
Danny Auble authored
-
Danny Auble authored
-
Danny Auble authored
to tell the code to profile or not. Prior to this anytime sstat was call a new entry was made in the h5 file when profiling potentially confusing the user as to what happened. This removes the extra entries.
-
Danny Auble authored
iterator.
-
Danny Auble authored
-
Danny Auble authored
update calls to acct_gather_energy_unpack which needs to know if it needs to be alloced or not.
-
Danny Auble authored
packable uint16_t
-
Danny Auble authored
-
Danny Auble authored
of just allocating 1.
-
- 15 Jun, 2015 11 commits
-
-
Danny Auble authored
-
Danny Auble authored
-
Danny Auble authored
warning right afterwards instead of after the job ran.
-
Danny Auble authored
-
Danny Auble authored
the fact.
-
Danny Auble authored
-
Danny Auble authored
-
Danny Auble authored
-
Danny Auble authored
-
Danny Auble authored
-
Yoann Blein authored
HDF5 code.
-
- 10 Jun, 2015 6 commits
-
-
Danny Auble authored
sh5util if needed.
-
Morris Jette authored
-
Morris Jette authored
-
Didier GAZEN authored
In your node_mgr fix to keep rebooted nodes down (commit 9cd15dfe), you forgot to consider the case of nodes that are powered up but are responding after ResumeTimeout seconds (the maximum time permitted). Such nodes are marked DOWN (because they didn't respond within ResumeTimeout seconds) than should become silently available when ReturnToService=1 (as stated in the slurm.conf manual) With your modification when such nodes are finally responding, they are seen as rebooted nodes and remain in the DOWN state (with the new reason: Node unexpectedly rebooted) even when ReturnToService=1 ! My patch to obtain the correct behaviour:
-
Morris Jette authored
Conflicts: doc/man/man5/slurm.conf.5 src/plugins/select/cons_res/job_test.c
-
Morris Jette authored
Equivalent fix as e1a00772 for select/serial rather than select/cons_res
-
- 09 Jun, 2015 7 commits
-
-
David Bigagli authored
-
Morris Jette authored
1. I submit a first job that uses 1 GPU: $ srun --gres gpu:1 --pty bash $ echo $CUDA_VISIBLE_DEVICES 0 2. while the first one is still running, a 2-GPU job asking for 1 task per node waits (and I don't really understand why): $ srun --ntasks-per-node=1 --gres=gpu:2 --pty bash srun: job 2390816 queued and waiting for resources 3. whereas a 2-GPU job requesting 1 core per socket (so just 1 socket) actually gets GPUs allocated from two different sockets! $ srun -n 1 --cores-per-socket=1 --gres=gpu:2 -p testk --pty bash $ echo $CUDA_VISIBLE_DEVICES 1,2 With this change #2 works the same way as #3. bug 1725
-
Morris Jette authored
-
Brian Christiansen authored
Bug 1572
-
Brian Christiansen authored
Bug 1572
-
Danny Auble authored
-
Danny Auble authored
-