Resource-based service classes control workload by guaranteeing specific resources to jobs within an SLA, ensuring jobs have priority within a dedicated share of resources. Once guaranteed resources are used up, SLA jobs are still able to run outside the guaranteed resource pool. A guaranteed resource pool can be based on hosts, slots, or shared resources such as licenses.
Resource-based service class scheduling for guarantee goals differs from time-based service class scheduling; the order in which jobs are scheduled does not change. Jobs are considered for dispatch according to whatever other scheduling features are configured, but have access to additional guaranteed resources. LSF tries to place jobs within a guarantee if possible.
The scheduler keeps track of how many resources are in each guaranteed resource pool, how many are reserved for each guarantee, and how many can be shared. Jobs belonging to guarantee SLAs are permitted to use resources from the resource pool until guarantees are met. Once guarantees are met, SLA jobs start consuming resources outside of the guarantee.
Loaning of guaranteed resources gives jobs outside of an SLA limited access to resources not in use by guarantee SLA jobs. By default LSF reserves sufficient resources in each guaranteed resource pool to honor all guarantees. Different configuration options allow loans to specific queues, short jobs, or jobs of any length.
Any guaranteed resources remaining idle at the end of a scheduling session may be loaned to jobs if loaning is enabled in the guaranteed resource pool (lsb.resources).
MultiCluster jobs under the job-forwarding model may be automatically attached to an SLA in the remote cluster using AUTO_ATTACH.
Guarantee SLA jobs can preempt other jobs and use preemption to meet a guarantee. Guarantee SLA jobs can only be preempted by queues with SLA_GUARANTEES_IGNORE=Y.
Guarantee SLAs cannot be used with EGO-enabled SLAs (ENABLE_DEFAULT_EGO_SLA in lsb.params).