Job priority behavior
Fair share
The default user-based fair share can be a factor in APS calculation by adding
the FS factor to APS_PRIORITY in the queue.
APScannot be used together with DISPATCH_ORDER=QUEUE.APScannot be used together with cross-queue fair share (FAIRSHARE_QUEUES). The QUEUE_GROUP parameter replaces FAIRSHARE_QUEUES, which is obsolete in LSF 7.0.APScannot be used together with queue-level fair share or host-partition fair share.
FCFS (first come first serve)
APS overrides the job sort result of FCFS.
SLA scheduling
APS cannot be used together with time-based SLAs with velocity, decline, or throughput goals.
Job re-queuing
All requeued jobs are treated as newly submitted jobs for APS calculation. The
job priority, system, and ADMIN APS factors are reset on re-queue.
Rerun jobs
Rerun jobs are not treated the same as requeued jobs. A job typically reruns because the host failed, not through some user action (like job re-queue), so the job priority is not reset for rerun jobs.
Job migration
Suspended (bstop) jobs and migrated jobs (bmig) are always scheduled before pending jobs. For migrated jobs, LSF keeps the existing job priority information.
If LSB_REQUEUE_TO_BOTTOM and LSB_MIG2PEND are
configured in lsf.conf, the migrated jobs keep their APS
information. When LSB_REQUEUE_TO_BOTTOM and LSB_MIG2PEND
are configured, the migrated jobs need to compete with other pending jobs based on the
APS value. If you want to reset the APS value, then you should use
brequeue, not bmig.
Resource reservation
The resource reservation is based on queue policies. The APS value does not
affect current resource reservation policy.
Preemption
The preemption is based on queue policies. The APS value does not affect the
current preemption policy.
Chunk jobs
The first chunk job to be dispatched is picked based on the APS priority. Other
jobs in the chunk are picked based on the APS priority and the default chunk job scheduling
policies.
- Submitting user
- Resource requirements
- Host requirements
- Queue or application profile
- Job priority
Backfill scheduling
Not affected.
Advance reservation
Not affected.
Resizable jobs
APS
value from the original job. The subsequent calculations use factors as follows:
| Factor or sub-factor | Behavior |
|---|---|
FAIRSHARE |
Resizable jobs submitting into fair share queues or host partitions are subject
to fair share scheduling policies. The dynamic priority of the user who submitted the job is the
most important criterion. LSF treats
pending resize allocation requests as a regular job and enforces the fair share user priority policy
to schedule them. The dynamic priority of users depends on:
Resizable job allocation changes affect the user priority calculation if RUN_JOB_FACTOR is greater than zero (0). Resize add requests increase number of slots in use and decrease user priority. Resize release requests decrease number of slots in use, and increase user priority. The faster a resizable job grows, the lower the user priority is, the less likely a pending allocation request can get more slots. |
MEM |
Use the value inherited from the original job |
PROC |
Use the MAX value of the resize request |
SWAP |
Use the value inherited from the original job |
JPRIORITY |
Use the value inherited from the original job. If the automatic job priority
escalation is configured, the dynamic value is calculated. For a requeued and rerun
resizable jobs, the For migrated resizable job,
the |
QPRIORITY |
Use the value inherited from the original job |
ADMIN |
Use the value inherited from the original job |