Hi all,
the reason to compile without optimization is to be able to have
a meaningful stack when attaching gdb to the daemons or when analysing
core files. If the optimization is on crucial variables in the stack are
optimized out preventing exact diagnoses of issues. This of course is
configurable, we only changed the default, if sites wish to compile with
optimization use the config option --disable-debug. So this is not about
sweeping bugs under the carpet it is exactly the opposite it is a tool
to debug more efficiently.
The reasons for using statvfs versus statfs is that statfs is deprecated
and replaced by the POSIX statvfs, so it is portable across platforms,
indeed NetBSD and Solaris do not have statfs.
Since all platforms have stavfs the code in get_tmp_disk() under the
#define (HAVE_STATFS) is obsolete and will possibly be removed in the
next major release.
On 04/24/2015 12:39 PM, Paul Edmon wrote:
Correction 50,000 jobs per day. That 1.5 million is per month. My
bad. Still no degradation in performance seen in our environment.
-Paul Edmon-
On 04/24/2015 03:31 PM, Chris Read wrote:
Re: [slurm-dev] Re: Slurm versions 14.11.6 is now available
On Fri, Apr 24, 2015 at 4:41 AM, Janne Blomqvist
<[email protected] <mailto:[email protected]>> wrote:
On 2015-04-24 02:03, Moe Jette wrote:
Slurm version 14.11.6 is now available with quite a few bug
fixes as
listed below.
Slurm downloads are available from
http://slurm.schedmd.com/download.html
* Changes in Slurm 14.11.6
==========================
[snip]
-- Enable compiling without optimizations and with debugging
symbols by
default. Disable this by configuring with --disable-debug.
Always including debug symbols is good (the only cost is a little
bit of disk space, should never really be a problem), but
disabling optimization by default?? In our environment, slurmctld
consumes a decent chunk of cpu time, I would loathe to see it
getting a lot (?) slower.
Typically, problems which are "fixed" by disabling optimization
are due to violations of the C standard or such which for some
reason just doesn't happen to trigger with -O0. Perhaps I'm being
needlessly harsh here, but I'd prefer if the bugs were fixed
properly rather than being papered over like this.
+1 from me...
-- Use standard statvfs(2) syscall if available, in
preference to
non-standard statfs.
This is not actually such a good idea. Prior to Linux kernel
2.6.36 and glibc 2.13, the implementation of statvfs required
checking all entries in /proc/mounts. If any of those other
filesystems are not available (e.g. a hung NFS mount), the statvfs
call would thus hang. See e.g.
http://man7.org/linux/man-pages/man2/statvfs.2.html
Not directly related to this change, there is also a bit of
silliness in the statfs() code for get_tmp_disk(), namely that it
assumes that the fs record size is the same as the memory page
size. As of Linux 2.6 the struct statfs contains a field f_frsize
which contains the correct record size. I suggest the attached
patch which should fix both of these issues.
--
Janne Blomqvist, D.Sc. (Tech.), Scientific Computing Specialist
Aalto University School of Science, PHYS & NBE
+358503841576 <tel:%2B358503841576> || [email protected]
<mailto:[email protected]>
--
Thanks,
/David/Bigagli
www.schedmd.com
