Eric Payne commented on YARN-2009:

bq. So we could take a max(guaranteed, used). Will this be fine?
I don't think so. If {{tq.getActuallyToBePreempted}} is non-zero, it represents 
the amount that will be preempted from what {{tq}} is currently using, not 
{{tq}}'s guaranteed resources. The purpose of this line of code is to set 
{{tq}}'s unallocated resources. But even if {{tq}} is below it's guarantee, the 
amount of resources that intra-queue preemption should consider when balancing 
is not the queue's guarantee, it's what the queue is already using. If {{tq}} 
is below its guarantee, inter-queue preemption should be handling that.

bq. app1 of user1 used entire queue. app2 of user2 asks more resource
The use case I'm referencing regarding this code is not regarding 2 different 
users. It's regarding the same user submitting jobs of different priorities. If 
{{user1}} submits a low priority job that consumes the whole queue, {{user1}}'s 
headroom will be 0. Then, when {{user1}} submits a second app at a higher 
priority, this code will cause the second app to starve because {{user1}} has 
already used up its allocation.

> Priority support for preemption in ProportionalCapacityPreemptionPolicy
> -----------------------------------------------------------------------
>                 Key: YARN-2009
>                 URL: https://issues.apache.org/jira/browse/YARN-2009
>             Project: Hadoop YARN
>          Issue Type: Sub-task
>          Components: capacityscheduler
>            Reporter: Devaraj K
>            Assignee: Sunil G
>         Attachments: YARN-2009.0001.patch, YARN-2009.0002.patch
> While preempting containers based on the queue ideal assignment, we may need 
> to consider preempting the low priority application containers first.

This message was sent by Atlassian JIRA

To unsubscribe, e-mail: yarn-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org

Reply via email to