Conflicts:
	META
	NEWS

Arguments in wrong order

timeout when talking to the Database is the same timeout so a race
condition could occur in the requesting client when receiving the response
if the database is unresponsive.

the entire cnode.

Under some conditions a step may be allocated fewer nodes than requested. Specifically, if the job uses the --exclusive --nodelist and in some fashion a higher node count, it may only be allocated the nodes in the specified node list. For example:
$ srun  -n2 --exclusive --ntasks-per-node=1 --cpus-per-task=4 -w smd1 hostname
smd1
smd1

This problem appears to only exist in version 14.11 and only applies to the step allocation, not the job allocation.

Fix SelectTypeParameters=CR_PACK_NODES for srun making both job and step
resource allocation. Previously a stand-long srun command would distribute
tasks evenly across the nodes.

see bug 1047

Conflicts:
	src/slurmctld/job_scheduler.c

Start a job in the highest priority partition possible, even if it requires
preempting other jobs and delaying initiation, rather than using a lower
priority partition. Previous logic would preempt lower priority jobs, but
then might start the job in a lower priority partition and not use the resources
released by the preempted jobs.
bug 1032

No change to logic

Improve the precision of several pthread_cond_timedwait() function
calls to be precise to the millisecond rather than rounding to the
neareast second. Applies to most scheduling functions.

Add retry logic related to cpu frequency manament locking.
Some general code improvements also

This should address various race conditions in setting CPU frequency,
especially as relates to gang scheduling (e.g. cancelling or terminating
jobs while near changing the running job).

of the pseudo terminal to the user.

Also don't try to map unset cpu-freq to lowest numeric value (was
looking for NO_VAL rather than zero)

even without it.