Conflicts:
	src/srun/srun.c

allocation.

NOTE: If you were setting the environment variable SLURMSTEPD_OOM_ADJ=-17,
it should be set to -1000 for Linux 2.6.36 kernel or later.

Send signal to srun and let aprun (like poe) forward the signals
rather than sending signal directly to the slurmd and tasks (not
applicable for aprun).

Conflicts:
	src/srun/libsrun/opt.c

and perhaps someone might find it useful).

One change is a check was added to see if Limits are enforced before
doing any of the work.  Before it wasn't part of the mix so some jobs
could get killed if limits were enforced and then turned off.

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.