[
https://issues.apache.org/jira/browse/YARN-8292?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16477674#comment-16477674
]
Eric Payne commented on YARN-8292:
----------------------------------
Thanks [[email protected]] and [~leftnoteasy].
[~leftnoteasy], Can you please clarify the following:
{noformat}
// - After preempt the container, the to-obtain should be either > 0
// OR any major resource equals to 0.
...
// * before: <30, 10, 5>, after <20, 10, -10>
{noformat}
In this proposal, should preemption continue after the above? After a container
is subtracted in the above example, {{resToObtain == <20, 10, -10>}} and the
next container request is {{<10, 15, 5>}}, would the process continue so we
would have the following?
{noformat}
// * before: <20, 10, -10>, after: <10, -5, -15>
{noformat}
> Fix the dominant resource preemption cannot happen when some of the resource
> vector becomes negative
> ----------------------------------------------------------------------------------------------------
>
> Key: YARN-8292
> URL: https://issues.apache.org/jira/browse/YARN-8292
> Project: Hadoop YARN
> Issue Type: Bug
> Components: yarn
> Reporter: Sumana Sathish
> Assignee: Wangda Tan
> Priority: Critical
> Fix For: 3.2.0, 3.1.1
>
> Attachments: YARN-8292.001.patch
>
>
>
> This is an example of the problem: (Same if we have more than 2 resources)
>
> Let's say we have 3 queues A/B/C. All containers with equal size <2,3>
>
> ||Queue||Guaranteed||Used ||Pending||
> |A|<20, 10>|<20,30>| |
> |B|<20, 10>|0|0|
> |C|<20, 10>|0|<20, 30>|
> | | | | |
>
> Under current logic, A's calculated to-preempt (how much resource other queue
> can preempt) will be <0, 20>. The preemption will not happen. However, under
> the context of DRC, queue A is using more resource than guaranteed, so queue
> C will be starved
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
