If FastSchedule=0 is configured and some nodes have not registered
for service (so we do not know their actual resource counts), then
leave the job pending rather than rejecting it without knowing if
it can run later (when the node registers and we know its specs).
bug 872

Rather than the numeric value

If a numeric value is not found in the function's table, print that
number rather than UNKNOWN.

For "scontrol --details show job" report the correct CPU_IDs when thre are
multiple threads per core (we are translating a core bitmap to CPU IDs).
This is an enhancement of commit 83d626ca
so the node table is only loaded once for the entire job table.
bug 850

Correct the record of CPU_IDs allocated to a job if there is more
than one CPU per core.

If job requests --exclusive then do not use nodes which have any cores in an
advanced reservation. Also prevents case where nodes can be shared by other
jobs.

Disable some logging that would be very slow unless
the _DEBUG flag is set in the plugin

If job requests --exclusive then do not use nodes which have any cores in an
advanced reservation. Previously the job would be allocated all of the cores
outside of the advanced reservation.

Correct support for partition with Shared=YES configuration.
Previous logic would share resources for jobs by default
(i.e. if user did not explicitly request --exclusive).
bug 758

This reording of some code results in cleaner logic

collapse the scheduling table when possible to reduce the
number of time slots to check for pending jobs. This should
improve performance considerably.

Previous logic was sometimes building incomplete map

When a decision is made to start a job, if for some
reason that job's start failed, the backfill scheduler
would previously just exit. With this change, it logs
the event and reserves the resources expected to be
used and continues down the job queue.

This change prevents creation of some back-to-back records with
the same resources, but different times.

No change in logic

Improved logging of backfill scheduling actions
Better handling of backfill_resolution logic to avoid creating
   some records that are not needed
Avoid creating some backfill scheduling maps with zero duration
The net effect should be slightly improved performance with no
   significant difference in action

Update slurm.conf man page for DebugFlag BackfillMap. This should be
considered part of commit 3c2bffb6

Add DebugFlag of BackfillMap. Previously a DebugFlag value of Backfill
logged information about what it was doing plus a map of expected resouce
use in the future. Now that very verbose resource use map is only logged
with a DebugFlag value of BackfillMap

Log not only the count of jobs tested since the last time locks
were released, but also the total job count since the backfill
scheduler started.

Remove duplicate backfill scheduling tests. For example there is
no need to test if a job can be started if the only difference
from the previous test involves nodes in other partitions that
can not be used by the job we are trying to start.

The backfill scheduler was always reporting the time that a job
was being considered as NOW rather than the time that was really
being considered.

decreases and total is less than in use.

This is a correction to commit 308b7432

Improve how failures in slurmd/slurmstepd communications are logged.

mail messages for job array events print now use the job ID using the
format "#_# (#)" rather than just the internal job ID.

This will help limit damage from two active primary slurmctld
(split brain problem).

it is already running.

Duplicate triggers are not not allowed

Job profiling leaves a file open