- 21 Jul, 2015 5 commits
-
-
Morris Jette authored
-
Chandler Wilkerson authored
This patch provides a rewrite of how /proc/cpuinfo is parsed in common_jag.c, as the original code made the incorrect assumption that cpuinfo follows a sane format across architectures ;-) The motivation for this patch is that the original code was producing stack smashing on a POWER7 running RHEL6.4 Red Hat adds -fstack-protector along with a lot of other protective CFLAGS when building RPMs. The code ran okay with -fno-stack-protector, but that is not the best work-around. So, the relevant /proc/cpuinfo line on an Intel (Xeon X5675) system looks like: cpu MHz : 3066.915 Whereas the relevant line in a POWER7 system is clock : 3550.000000MHz My patch replaces the assumption that the relevant number starts 11 characters into the string with another assumption: That the relevant number starts two characters after a colon in a string that matches (M|G)Hz. All in all, the function has a few more calls, which may be a performance issue if it has to be called multiple times, but since the section I edited only gets evaluated if we don't know the cpu frequency, getting it right will actually result in fewer string operations and unnecessary opens of /proc/cpuinfo for systems likewise affected. Finally, I also read the actual value into a double and multiply it up to the size indicated by the suffix, so we end up with KHz? It was unclear what the original code intended, since it matched both MHz and GHz, replaced the decimal point with a zero, and read the result as an int. -- Chandler Wilkerson Center for Research Computing Rice University
-
Danny Auble authored
This reverts commit 2c95e2d2. Conflicts: src/plugins/select/alps/basil_interface.c This is related to bug 1822. It isn't clear why the code was taken out in this commit in the first place and based off of commit 2e2de6a4 (which is the reason for the conflict) we tried unsuccessfully to put it back. It appears the only difference here is the addition of always setting mppnppn = 1 instead of always to job_ptr->details->ntasks_per_node when no ntasks is set. This appears to only be an issue with salloc or sbatch as ntasks is always set for srun.
-
Morris Jette authored
-
david authored
-
- 20 Jul, 2015 1 commit
-
-
Morris Jette authored
-
- 18 Jul, 2015 2 commits
-
-
Brian Christiansen authored
Prevent slurmctld abort on update of advanced reservation that contains no nodes. bug 1814
-
Brian Christiansen authored
Bug 1810
-
- 17 Jul, 2015 6 commits
-
-
Morris Jette authored
srun command line of either --mem or --mem-per-cpu will override both the SLURM_MEM_PER_CPU and SLURM_MEM_PER_NODE environment variables. Without this change, salloc or sbatch setting --mem-per-cpu (or a configuration of DefMemPerCPU) would over-ride the step's --mem value.
-
Danny Auble authored
change was made.
-
Morris Jette authored
-
Nicolas Joly authored
-
Danny Auble authored
when removing a limit from an association on multiple clusters at the same time.
-
Danny Auble authored
to gain the correct limit when a parent account is root and you remove a subaccount's limit which exists on the parent account.
-
- 16 Jul, 2015 6 commits
-
-
Morris Jette authored
This fixes changes made in commit d4d51de7 Which fails for a job state of Pending (needed to special case the zero value).
-
Morris Jette authored
-
Morris Jette authored
abort if specified acct_gather_energy plugin can not be loaded rather than deadlocking bug 1797
-
Morris Jette authored
-
Morris Jette authored
Under some conditions if an attempt to schedule the last task of a job array (the meta-record of the job array) fails, it's task ID will be changed from the appropriate value to NO_VAL. bug 1790
-
Morris Jette authored
-
- 15 Jul, 2015 7 commits
-
-
Morris Jette authored
-
Nathan Yee authored
-
Nathan Yee authored
-
Nathan Yee authored
Bug 1798
-
Morris Jette authored
If a job can only be started by preempting other jobs, the old logic could report the error: "cons_res: sync loop not progressing, holding job #" due to the usable CPUs and GRES needed by the pending job not matching. This change prevents the error message and job hold when job preemption logic is being used. The error message and job hold still take place for job scheduling outside of preemption, which will match CPUs and GRES at the beginning. bug 1750
-
Morris Jette authored
Under some conditions the select/cons_res plugin will hold a job, setting it's priority to zero and reason to HELD. The logic in slurmctld's main scheduling loop previously kept its priority at zero, but changed the reason from HELD to RESOURCES. This change leaves the proper job state as set by the select plugin. This may be related to bug 1750
-
Morris Jette authored
The backfill scheduler will periodically release locks for other actions. If a job is held during the time that locks were released, that job might still have been scheduled by the backfill scheduler (i.e. it failed to check for a job with a priority of zero). could be a root cause for bug 1750
-
- 14 Jul, 2015 3 commits
-
-
Danny Auble authored
-
Morris Jette authored
Previous logic could fail to update some tasks of a job array for some fields. bug 1777
-
Morris Jette authored
Add level to switch table information logged by select plugin
-
- 13 Jul, 2015 3 commits
-
-
Morris Jette authored
Old logic could purge a job record for a job that was in completing state (if there was also a lot of agent threads). This change prevents purging job records for completing jobs.
-
Morris Jette authored
Fix to job array update logic that can result in a task ID of 4294967294. To reproduce: $ sbatch --exclusive -a 1,3,5 tmp Submitted batch job 11825 $ scontrol update jobid=11825_[3,4,5] timelimit=3 $ squeue JOBID PARTITION NAME USER ST TIME NODES NODELIST(REASON) 11825_3 debug tmp jette PD 0:00 1 (None) 11825_4 debug tmp jette PD 0:00 1 (None) 11825_5 debug tmp jette PD 0:00 1 (None) 11825 debug tmp jette PD 0:00 1 (Resources) A new job array entry was created for task ID 4 and the "master" job array record now has a task ID of 4294967294. The logic with the bug was using the wrong variable in a test. bug 1790
-
Gene Soudlenkov authored
Bug 1799
-
- 10 Jul, 2015 4 commits
-
-
Morris Jette authored
remove new capabilities added in comit ad9c2413 Leave the new logic only in version 15.08, which has related performance improvements in the slurmctld agent code, see commit 53534f49
-
Morris Jette authored
Correct "sdiag" backfill cycle time calculation if it yields locks. A microsecond value was being treated as a second value resulting in an overflow in the calcuation. bug 1788
-
Morris Jette authored
-
Morris Jette authored
-
- 09 Jul, 2015 1 commit
-
-
Morris Jette authored
The slurmctld logic throttles some RPCs so that only one of them can execute at a time in order to reduce contention for the job, partition and node locks (only one of the effected RPCs can execute at any time anyway and this lets other RPC types run). While an RPC is stuck in the throttle function, do not count that thread against the slurmctld thread limit. but 1794
-
- 08 Jul, 2015 2 commits
-
-
Morris Jette authored
-
Danny Auble authored
-