Preempting Tokens

There are families of tools that use different numbers of tokens per license. The number of tokens used depends on the application. For example, the family Cadence Multi-Mode simulators contains tools such as Spectre, AMS, and UltraSim, using 1, 2, and 6 tokens respectively. These families of tools require special attention when configuring preemption.

In the following examples, it is assumed there are eight groups of users (My1, ..., My8) competing for the tokens, represented by the resource map MyTokens. It is also assumed that the jobs are assigned to different jobclasses: spectre, ams, and ultrasim.

Three types of preemption will be set up:
  • Based on priority, restricted to jobs belonging to the same user
  • Based on ownership
  • Based on avoiding starvation of multi-token jobs by reserving tokens

Priority-based Preemption for Tokens

In this rule, a high priority job is allowed to preempt a low priority job that is in the same jobclass and is owned by the same user. The preempting jobs need to be waiting for the MyTokens resource. Jobs younger than 20 seconds are killed and resubmitted; they are not suspended or resumed. 
    # Fragment of vnc.swd/vovpreemptd/config.tcl
    VovPreemptRule -rulename MyPriSameUser \
        -preempting "priority>=8" \
        -waitingfor MyTokens \
        -preemptable "jobclass==@JOBCLASS@ user==@USER@ priority<4" \
        -killage 20 \
        -pool contract:My

The only difference between the preemption on tokens and the preemption on regular license is the use of the pool contract:My. This pool is used for the rules based on Ownership, which is described in the following section. In a given preemption cycle, the ownership rules will not fire if the MyPriSameUserK rule is fired.

Avoid Starvation for Tokens

With mixed workloads of spectre and ultrasim jobs, it is difficult for an ultrasim job to be scheduled. It is also difficult for six tokens to be available at the same time, as spectre jobs will likely take all the tokens as the tokens become available. This starvation for the ultrasim jobs can be prevented by reserving tokens for the ultrasim jobs as described in the following example.

In this example, for jobs in the ultrasim class, if a job that has at least normal priority and has been waiting for more than 2 minutes, 6 tokens are reserved for the top job for a period of 1 minute. As this reservation is renewed at every cycle, the reservation period does not need to be long. A subordinate rule in the same pool takes care of the jobs in the ams class.

Note:
  • The resource reservations for a specific job are automatically dismissed when the job is no longer in the queue because it is either dispatched or descheduled.
  • It is not necessary to specify the resources to be reserved, as that is automatically computed.
The same pool, My:reserve, is used for both ultrasim and ams. This is to not have both rules to fire in each cycle. Having reserved tokens for the ultrasim jobs, it is not desirable to also reserve tokens for ams, as ams would likely prevail. 
# Fragment of vnc.swd/vovpreemptd/config.tcl
VovPreemptRule -rulename MyAntiStarvationUltrasim \
    -preempting "jobclass==ultrasim priority>=4" \
    -bucketage  "2m" \
    -method  "RESERVE" \
    -reservetime  1m -reservenum 6 \
    -pool "My:reserve"

VovPreemptRule -rulename MyAntiStarvationAms \
    -preempting "jobclass==ams priority>=4" \
    -bucketage  "2m" \
    -method  "RESERVE" \
    -reservetime  1m -reservenum 2 \
    -pool "My:reserve"