- 23 Jul, 2015 17 commits
-
-
Danny Auble authored
-
Danny Auble authored
-
Danny Auble authored
changes.
-
Danny Auble authored
-
Danny Auble authored
-
Danny Auble authored
-
Danny Auble authored
-
Danny Auble authored
-
Danny Auble authored
-
Danny Auble authored
-
Danny Auble authored
-
Danny Auble authored
-
Danny Auble authored
-
Danny Auble authored
-
Danny Auble authored
slurmdb_find_tres_count_in_string
-
Danny Auble authored
This should be all removed by the time we are actually working correctly.
-
Danny Auble authored
-
- 22 Jul, 2015 19 commits
-
-
Danny Auble authored
-
Danny Auble authored
-
Danny Auble authored
-
Danny Auble authored
-
Danny Auble authored
-
Danny Auble authored
slurmdb.h slurmdb_def.*
-
Danny Auble authored
-
Danny Auble authored
a while ago with SLURM_MIN_PROTOCOL_VERSION
-
Danny Auble authored
-
Danny Auble authored
-
Danny Auble authored
-
Morris Jette authored
-
Nicolas Joly authored
Previously only batch job completions were being captured. bug 1820
-
Morris Jette authored
-
Morris Jette authored
-
David Bigagli authored
-
Morris Jette authored
If a job was running on the node when slurmctld restarted. The slurmd would notify slurmctld when the job ended and slurmctld would change its state from UNKNOWN to IDLE, at least if the job termination happened prior to the slurmd being asked for configuration information. The configuration information might then not be collected for some time. I've modified the code to address this problem and try to collect configuration information from every node after slurmctld startup, eliminating this race condition. bug 1805
-
Danny Auble authored
-
Brian Christiansen authored
Bug 1208
-
- 21 Jul, 2015 4 commits
-
-
Danny Auble authored
as rewrite of the cache functionality from CSCS to work with TRES and rename it to be assoc_mgr_info instead of generic cache.
-
Morris Jette authored
-
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
-