LSF preemption with License Scheduler preemption

For LSF jobs the parameter MAX_JOB_PREEMPT sets the maximum number of times a job can be preempted. MAX_JOB_PREEMPT can be defined in lsb.params, lsb.queues, or lsb.applications, with the application setting overriding the queue setting and the queue setting overriding the cluster-wide lsb.params definition.

Jobs belonging to a license project that has ownership in License Scheduler can trigger preemption even when no more slots are available in LSF. Configured together with LSF_LIC_SCHED_PREEMPT_SLOT_RELEASE, license job preemption works together with LSF slot-based preemption.

Example

Project proj1 has ownership of 3 of the license AppX.

MXJ = 5, and LSF_LIC_SCHED_PREEMPT_SLOT_RELEASE=Y is configured in lsf.conf.

5 jobs are submitted and started using AppX, in proj2. Then 2 jobs are submitted to proj1, and pend waiting for a AppX license token. Although the slots are full, the request is sent to License Scheduler, which recognizes the ownership and preempts 2 jobs in proj2. The jobs are suspended, both their licenses and slots are released, and the 2 jobs in proj1 can run.

LSF JOB_CONTROLS configuration

If the LSF administrator has defined JOB_CONTROLS in lsb.queues so that job controls (such as the signal SIGTSTP) take effect whe License Scheduler preemption occurs, LIC_SCHED_PREEMPT_STOP=Y in lsf.conf must also be defined for License Scheduler preemption to work.