Mailing-List: contact issues-help@aurora.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@aurora.apache.org
Date: Mon, 13 Apr 2015 20:59:12 +0000 (UTC)
From: "Chris Lambert (JIRA)" <jira@apache.org>
To: issues@aurora.apache.org
Message-ID: <JIRA.12784893.1427132777000.74951.1428958752436@Atlassian.JIRA>
In-Reply-To: <JIRA.12784893.1427132777000@Atlassian.JIRA>
References: <JIRA.12784893.1427132777000@Atlassian.JIRA>
 <JIRA.12784893.1427132777549@arcas>
Subject: [jira] [Updated] (AURORA-1219) Improve preemptor efficiency
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


     [ https://issues.apache.org/jira/browse/AURORA-1219?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Chris Lambert updated AURORA-1219:
----------------------------------
    Story Points: 5

> Improve preemptor efficiency
> ----------------------------
>
>                 Key: AURORA-1219
>                 URL: https://issues.apache.org/jira/browse/AURORA-1219
>             Project: Aurora
>          Issue Type: Task
>          Components: Scheduler
>            Reporter: Maxim Khutornenko
>            Assignee: Maxim Khutornenko
>
> While AURORA-1158 makes the preemptor asynchronous and helps scheduling loop performance, it loses some preemption efficiency due to adapting the original algorithm to work asynchronously:
> - Preemptor repeatedly searches for preemption slots with the same ClusterState increasing the probability of victim collisions. 
> - Slave/offer/resource mappings are redundantly recomputed for every pending task slot search.
> - Pending tasks are repeatedly sized up against every slave (as opposed to the other way around) making internal loop optimizations more expensive (i.e. pending task count is expected to be << slave count under normal conditions).


--
This message was sent by Atlassian JIRA
(v6.3.4#6332)