aurora-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mehrdad Nurolahzade (JIRA)" <>
Subject [jira] [Created] (AURORA-1867) Consider reserving for multiple tasks per preemption round
Date Wed, 21 Dec 2016 17:59:59 GMT
Mehrdad Nurolahzade created AURORA-1867:

             Summary: Consider reserving for multiple tasks per preemption round
                 Key: AURORA-1867
             Project: Aurora
          Issue Type: Story
          Components: Scheduler
            Reporter: Mehrdad Nurolahzade
            Priority: Minor

To be fair, {{PendingTaskProcessor}} interleaves tasks from different groups:
// The algorithm below attempts to find a reservation for every task group by matching
// it against all available slaves until a preemption slot is found. Groups are evaluated
// in a round-robin fashion to ensure fairness (e.g.: G1, G2, G3, G1, G2).
// A slave is removed from further matching once a reservation is made. Similarly, all
// identical task group instances are removed from further iteration if none of the
// available slaves could yield a preemption proposal.

However, this fairness comes at the price of increasing proposal time. Even if preemption
proposals are sought for the same task group, the processor would still restart iterating
slaves for each task instance. This results in reevaluating all slaves already rejected in
a previous search before it finds a new proposal.

If search time is substantial, then {{PendingTaskProcessor}} performance can be improved,
at the cost of reduced fairness, by adopting a strategy similar to [AURORA-1771]. In other
words, {{PendingTaskProcessor}} can look for a maximum of _N_ candidates per task group in
each iteration over the list of slaves.

This message was sent by Atlassian JIRA

View raw message