You are viewing an old version of this page. View the current version.

    Compare with Current View Page History

    Version 1 Next »

    Since there are so many variables that an affect when and whether a particular job is dispatched to a worker, it might help if some of the decisions involved in this process were described in a bit of detail.

    There are 3 different times that selection occurs:

    1. when a job slot becomes available
    2. when a job is submitted, retried, unblocked, or shoved (supervisor is explicitly instructed to re-evaluate the job)
    3. when a global resource becomes available

    When a slot on a worker becomes available:

    Selection criteria:
      • pending state: jobs with pending instances are selected
      • job requirements: these pending instances are filtered by requirements; can the worker meet them?
      • job reservations: can the worker honour the reservations for the resources specified in the reservations?

    Sorting is done at the same time as filtering ("selection criteria") is done-- i.e., in the same loop, when a job passes the "selection" criteria, 
    it's inserted into the appropriate position in the sorted list. The sorting is based on the algorithm selected with the supervisor_queue_algorithm parameter

    The default sorting criteria are:
      • job cluster: jobs whose cluster matches the worker's are moved to the top of the list
      • job priority: priority is used as the tie-breaker when cluster is the same
      • job ID: since the jobID is based on submission time, the tie-breaker when cluster and priority are the same is essentially "first come, first served".

    When a job is submitted, retried, unblocked, or shoved:

    The job's cluster and priority are compared to all running job instances to see if there are any running jobs that this new job can preempt. Some jobs have a flag set that indicates that they can never be preempted, these are filtered out of the list.

    If there are preemptable jobs, the workers that these jobs are running on are checked to see if they can satisfy the job's requirements and reservations

    if the requirements and reservations can be met by a particular worker, then the job instance that is running on that worker is marked for preemption, and depending on the supervisor's preemption policy (passive or aggressive), the job instance is preempted as follows:

    • passive preemption: when the job instance finishes the frame it's currently working on
    • aggressive premption: the job instance is killed immediately, and both the instance and the frame get put back into the queue in a pending state

    There's a couple of major things that happen before preemption:

    1. the list of hosts are filtered down, just like the list of jobs are filtered above, using criteria such as the job's requirements and the queuing algorithm's host-job pair match/reject routines.
    2. then the supervisor tries to find open/idle slots for the job in consideration, from the filtered down list of hosts, and dispatches instances if slots are found.
    3. if there are still pending instances remaining for the job, preemption occurs.
    • No labels