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=Y in lsf.conf, license job preemption works together with LSF slot-based preemption. Configured together PREEMPTABLE_RESOURCES=mem in lsb.params and LSF_LIC_SCHED_PREEMPT_SLOT_RELEASE=Y in lsf.conf, license job preemption works together with LSF memory resource 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.

Five jobs are submitted and started with AppX, in proj2. Then, two 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 two jobs in proj2. The jobs are suspended, both their licenses and slots are released, and the two jobs in proj1 can run.

LSF JOB_CONTROLS configuration

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