enforcing a QOS doesn't have anything to do with enforcing a limit if a
QOS is used.

Signed-off-by: Danny Auble <da@schedmd.com>

running the perf profiler on slurmctld on our production cluster (with select/cons_res) showed that with our configuration & workload highest up in the profile are calls to difftime() and _cr_job_list_sort(), in total accounting for ~37% of the total runtime.

By sacrificing some theoretical portability by replacing the calls to difftime() with a simple inline subtraction that 37% should be substantially reduced.

As I saw identical code also in the linear and serial plugins, I fixed those in the same manner, although I don't know if this performance issue turns up when using those plugins.

Conflicts:
	NEWS
	configure
	doc/html/cray.shtml

than BGQ.

Remove some unused variables and minor reformatting to conform
with Linux kernel coding standard

aprun process instead of a perl script.

Conflicts:
	configure
	doc/html/documentation.shtml
	src/common/cpu_frequency.c
	src/common/slurm_jobacct_gather.c
	src/common/slurm_protocol_defs.c
	src/common/slurm_protocol_defs.h
	src/plugins/accounting_storage/mysql/as_mysql_job.c
	src/sstat/sstat.c

The patch contains:
1) general code cleanup
2) documentation concerning the energy framework
3) fix for sstat header/data mismatch problem
4) changes on the rapl plugin to print the average power consumption between 2 measurements
in place of an instantaneous value:  this is printed for CurrentWatts value of "scontrol show node"
5)the memory leak that Moe located on cpu frequency code

we are currently working on the following :
- the requested frequency as described by Martin
- rapl fine grain measurements (socket level)
- the ipmi plugin based on freeipmi

and we hope to have them either during your 2.5.0.rc1 testing period or for the 2.5.1

we recently saw an issue where on a couple clusters the age priority of almost all jobs had been zeroed. Restarting slurmctld did "solve" the issue, though I'm not really sure why it occured in the first place. One suspicion is that it was due to the recent DST transition (occured on Oct 28th over here), and that this somehow wedged the calculation of the age priority.

Looking at the code, I couldn't really find any obvious fault, but anyway, by avoiding the usage of broken-down time (which includes DST information) in the calculation of the start_time this sort of bug could at least be avoided.

The attached patch implements the above for the priority multifactor plugins.

the attached patch changes the default timestamp format in logfiles to conform to RFC 5424 (the current version of the syslog RFC). It is identical to the current default "ISO 8601" timestamp used by slurm, with the exception that the timezone offset is appended. This has the benefits of

1) It's unambiguous.

2) Avoids potential confusion for admins running cluster(s) in different timezones.

3) Might help debug issues related to DST transitions. (More on that later..)

(To be pedantic, a RFC 5424 timestamp is still a valid ISO 8601 timestamp, but the converse is not necessarily true. So there is RFC 3339 which is a "profile" of ISO 8601, that is a subset, recommended for internet protocols. The RFC 5424 timestamp, in turn, is a subset of the RFC 3339 timestamps.)

The previous behavior of can be used by running configure with the

--disable-rfc5424time

flag.

Conflicts:
	NEWS
	src/common/slurm_protocol_api.c
	src/plugins/select/cray/basil_interface.c
	src/srun/libsrun/opt.c
	src/srun/srun_job.c

We need to test more to insure that HWLOC maps boards and only boards
to group objects

Preserve original logic, but move into common location to avoid duplicate
code, which can also lead to confusion