Reserving resources for an allocation plan

In order to enact the current allocation plan, LSF uses the existing reservation mechanism to hold resources idle as needed for plans. As a general principle, LSF will try to reserve as few resources as possible in order to enact the plan.

When deciding how many resources to reserve, LSF considers not only the raw resource availability (that is, slots, memory, licenses, etc.), but also things like configured limits. For example, if a slot limit is configured for a user, and in the plan the user uses up to 100 slots concurrently, then LSF may need to reserve up to 100 slots for that user’s PEND jobs in order to ensure that the plan can be carried out.

Due to such concerns, the amount of resources reserved on a host may exceed the capacity of the host in some cases. Reservations may also exceed configured limits.

As in LSF releases before version 10.1.0.5, the resources reserved for a job can be viewed using the bjobs –l command. The slots / tasks reserved on a host can be viewed using the bhosts command.

When a job is reserving resources for a planned allocation, the planned allocation becomes sticky in that LSF will not consider searching for a better (earlier) planned allocation for the job once it starts reserving. Contrast this with jobs that do not reserve. For these, LSF will continuously look in the planner to place the job where it will start earliest.