You are here: 21 Preemption > References > Preemption Flags

21.6 Preemption Flags

Using QoS, you can specify preemption rules and control access to preemption privileges. This allows you to increase system throughput, improve job response time for specific classes of jobs, or enable various political policies. You enable all policies by specifying some QoS credentials with the QFLAGS PREEMPTEE, and others with PREEMPTOR.

PREEMPTEE
Description Indicates that the job can be preempted by a higher-priority job.
Use Use for lower-priority jobs that can be preempted.
Notes

This may delay some node actions. When reprovisioning, the system job may expire before the provision action occurs; while the action will still occur, the job will not show it.

Example
QOSCFG[test1] QFLAGS=PREEMPTEE MEMBERULIST=<user> PRIORITY=100
PREEMPTOR
Description Indicates that the job should take priority and preempt any PREEMPTEE jobs.
Use Use for jobs that need to take precedence over lower-priority jobs.
Notes

PREEMPTOR jobs, either queued or running, must have a higher priority than PREEMPTEE jobs.

When you configure job as a PREEMPTOR, you should also increase its priority (for details, see PREEMPTPRIOJOBSELECTWEIGHT and PREEMPTRTIMEWEIGHT).

Example
QOSCFG[test2] QFLAGS=PREEMPTOR MEMBERULIST=<user> PRIORITY=10000

21.6.1 Additional preemptor and preemptee information

Preemptor priority plays a big role in preemption. Generally, you should assign the preemptor job a higher priority value than any other queued jobs so that it will move to (or near to) the top of the eligible queue.

You can set the RESERVATIONPOLICY parameter to NEVER. With this configuration, preemptee jobs can start whenever idle resources become available. These jobs will be allowed to run until a preemptor job arrives, at which point the preemptee jobs are preempted, freeing the resource. This configuration allows near immediate resource access for the preemptor jobs. Using this approach, a cluster can maintain near 100% system utilization while still delivering excellent turnaround time to the most important jobs.

In environments where job checkpointing or job suspension incur significant overhead, you might want to constrain the rate at which job preemption is allowed. You can use the JOBPREEMPTMINACTIVETIME parameter to throttle job preemption. In essence, this parameter prevents a newly started or newly resumed job from being eligible for preemption until it has executed for a specified amount of time. Conversely, you can exclude jobs from preemption after they have run for a certain amount of time by using the JOBPREEMPTMAXACTIVETIME parameter.

Related Topics 

© 2016 Adaptive Computing