Platform LSF Administration Guide Version 6.2

Time-based Slot Reservation
Administering Platform LSF
348
Time-based Slot Reservation
Existing LSF slot reservation works in simple environments, where host-based MXJ
limit is only constraint to job slot request. In complex environments, where more than
one constraints exist, for example job topology or generic slot limit:
◆ Estimated job start time becomes inaccurate
◆ The scheduler makes a reservation decision that can postpone estimated job start
time or decrease cluster utilization.
Current slot reservation by start time (RESERVE_BY_STARTTIME) resolves several
reservation issues in multiple candidate host groups, but it cannot help on other cases:
◆ Special topology requests, like span[ptile=n]
◆ Only calculates and displays reservation if host has free slots. Reservations may
change or disappear if there are no free CPUs; for example, if a backfill job takes all
reserved CPUs.
◆ For HPC machines containing many internal nodes, host-level number of reserved
slots is not enough for administrator and end user to tell which CPUs the job is
reserving and waiting for.
Time-based slot reservation vs. greedy slot reservation
With time-based reservation, a set of pending jobs will get future allocation and an
estimated start time, so that job can be placed in the future. Reservations are made based
on future allocation to guarantee estimated start time.
Start time and
future allocation
The estimated start time for a future allocation is the earliest start time when all
considered job constraints are satisfied in the future. There may be a small delay of a few
minutes between the job finish time on which the estimate was based and the actual start
time of the allocated job.
If a job cannot be placed in a future allocation, the scheduler uses greedy slot reservation
to reserve slots. Existing LSF slot reservation is a simple greedy algorithm:
◆ Only considers current available resources and minimal number of requested job
slots to reserve as many slots as it is allowed
◆ For multiple exclusive candidate host groups, scheduler goes through those groups
and makes reservation on the group that has the largest available slots
◆ For estimated start time, after making reservation, scheduler sorts all running jobs
in ascending order based on their finish time and goes through this sorted job list
to add up slots used by each running job till it satisfies minimal job slots request.
The finish time of last visited job will be job estimated start time.
Reservation decisions made by greedy slot reservation will not have an accurate
estimated start time or information about future allocation. The calculated job start time
used for backfill scheduling is uncertain, so
bjobs displays:
Job will start no sooner than indicated time stamp