- 22 May, 2014 1 commit
-
-
Morris Jette authored
-
- 21 May, 2014 12 commits
-
-
Morris Jette authored
This reverts commit 859839a7 The ntasks_per_core option was previously really treated like number of CPUs (rather than tasks) to allocate per core, which seems to be what is desired.
-
Morris Jette authored
This needs a lot of work, but checking in the framework for now.
-
David Bigagli authored
-
Danny Auble authored
-
Danny Auble authored
-
Danny Auble authored
wait for.
-
Danny Auble authored
based on the mask given.
-
Danny Auble authored
task/affinity.
-
Danny Auble authored
thread in a core.
-
Danny Auble authored
it can bind cyclically across sockets.
-
Danny Auble authored
0c090f95
-
Morris Jette authored
add a PriorityFlags option of CALCULATE_RUNNING. If set, then the priority of running jobs will continue to be recalculated periodically. The PriorityFlags value reported by sview and "scontrol show config" will be reported as a string rather than its numeric value.
-
- 20 May, 2014 9 commits
-
-
Morris Jette authored
-
Morris Jette authored
-
Morris Jette authored
Previous logic assumed cpus_per_task=1, so ntasks_per_core option could spread the job across more cores than desired
-
Morris Jette authored
cpus-per-task support: Try to pack all CPUs of each tasks onto one socket. Previous logic could spread the tasks CPUs across multiple sockets.
-
Morris Jette authored
Previous logic was counting CPUs, but assuming each task would only use one CPU.
-
Dan Weeks authored
-
Danny Auble authored
This reverts commit b22268d8.
-
Danny Auble authored
-
Morris Jette authored
-
- 19 May, 2014 11 commits
-
-
Morris Jette authored
-
Morris Jette authored
-
Nathan Yee authored
-
Morris Jette authored
-
Morris Jette authored
-
Morris Jette authored
Conflicts: src/slurmctld/job_mgr.c
-
Morris Jette authored
Properly enforce job --requeue and --norequeue options. Previous logic was in three places not doing so (either ignoring the value, ANDing it with the JobRequeue configuration option or using the JobRequeue configuration option by itself). bug 821
-
Morris Jette authored
-
Morris Jette authored
Add support for a job step's CPU governor and/or frequency to be reset on suspend/resume (or gang scheduling). The default for an idle CPU will now be "ondemand" rather than "userspace" with the lowest frequency (to recover from hard slurmd failures and support gang scheduling).
-
Morris Jette authored
-
Morris Jette authored
There should be no change in behavior with the production code, but this will improve the robustness of the code if someone makes changes to the logic.
-
- 17 May, 2014 1 commit
-
-
Morris Jette authored
Always set to default values if no user input This is needed to clear any vestigial values from abnormal Slurm termination.
-
- 16 May, 2014 3 commits
-
-
Morris Jette authored
Used uninitialized variable in using the srun --cpu-freq option to set the CPU governor, resulting in invalid memory reference. Some minor cosmtic changes too.
-
Morris Jette authored
Add srun --cpu-freq options to set the CPU governor (OnDemand, Performance, Conservative, PowerSave or UserSpace). task/affinity: support set cpu_freq without cpuset (using hwloc and sched functions) Fix calculation used to set --cpu-freq=highm1 (relied upon ordering of possible CPU frequencies).
-
Morris Jette authored
The suspend/resume is performed on a per-job basis, but the cpu_freq is set on a per job step basis. This is a partial reversion of commit 5e40f627
-
- 15 May, 2014 3 commits
-
-
Morris Jette authored
-
Morris Jette authored
Add SelectTypeParameters option of CR_PACK_NODES to pack a job's tasks tightly on its allocated nodes rather than distributing them evenly across the allocated nodes. bug 819
-
Morris Jette authored
Job allocaitons with core specialization are allocated all available CPUs on the selected nodes rather than only the number required to satisfy their allocation request (e.g. "srun --core-spec=1 -n1 date" will not be allocated 1 CPU, but will get the entire node except for one specialized core).
-