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)
