Slurm uses what is known as a conservative backfill scheduling
algorithm. No job will be started that adversely impacts the expected
start time of _any_ higher priority job. The scheduling can also be
effected by a job's requirements for memory, generic resources,
licenses, and resource limits.
Moe Jette
SchedMD LLC
Quoting Bill Wichser <[email protected]>:
Just a question on expected behavior of the backfill scheduler. This
is an SMP machine if that matters. Scheduler is backfill with no
preemption.
I have a number of jobs queued. There are three which matter,
ordered by priority. In the current state I have 60 free cores.
job 201 needs 200 cores and will start in 1 hour requiring 24 hours
of runtime
job 202 needs 250 cores and will start in 5 hours requiring 24 hours
of runtime
...
job 300 needs 30 cores and will start in 300 hours requiring 2 hours
of runtime
The job completing in 1 hour will free 252 cores.
Clearly, starting job 300 will not impact job 201's start time in
any way. Yet it will not start since the time overlaps the expected
1 hour start time of job 201. Is this the expected behavior? I
haven't yet checked the source code to verify that this just looks
at the trivial impact on the next job but I'd expect the scheduler
to be able to look a little deeper than this.
Bill
