You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@aurora.apache.org by "Mehrdad Nurolahzade (JIRA)" <ji...@apache.org> on 2016/12/21 17:59:59 UTC

[jira] [Created] (AURORA-1867) Consider reserving for multiple tasks per preemption round

Mehrdad Nurolahzade created AURORA-1867:
-------------------------------------------

             Summary: Consider reserving for multiple tasks per preemption round
                 Key: AURORA-1867
                 URL: https://issues.apache.org/jira/browse/AURORA-1867
             Project: Aurora
          Issue Type: Story
          Components: Scheduler
            Reporter: Mehrdad Nurolahzade
            Priority: Minor


To be fair, {{PendingTaskProcessor}} interleaves tasks from different groups:
{code:title=PendingTaskProcessor.java}
// 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.
{code}

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
(v6.3.4#6332)