aurora-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mehrdad Nurolahzade (JIRA)" <>
Subject [jira] [Assigned] (AURORA-1867) Consider reserving for multiple tasks per preemption round
Date Fri, 06 Jan 2017 17:25:58 GMT


Mehrdad Nurolahzade reassigned AURORA-1867:

    Assignee: Mehrdad Nurolahzade

> Consider reserving for multiple tasks per preemption round
> ----------------------------------------------------------
>                 Key: AURORA-1867
>                 URL:
>             Project: Aurora
>          Issue Type: Story
>          Components: Scheduler
>            Reporter: Mehrdad Nurolahzade
>            Assignee: 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.
> {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

View raw message