[ 
https://issues.apache.org/jira/browse/YARN-5889?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15755304#comment-15755304
 ] 

Wangda Tan commented on YARN-5889:
----------------------------------

bq. For preemption calculation, one of the main problem could have been about 
the free resources
I think so, but I think the *minimum* preemption threshold is we should not 
preempt res from user if used of the user < queue-capacity * MULP. The higher 
threshold is, the safer of the preemption. 

bq. I think in a busier and short-living app's cluster, we may recalculate more.
I agree with [~eepayne], we should be able to make preemption / allocation UL 
calculation independent (or at least it's better to not allocation UL has 
dependency on preemption UL). [~sunilg] could you add some details here?

bq. On this note, could I update a patch with approach mentioned above.
Please go ahead when you get chance :). We should generally agree the approach, 
there are some debatable details, but starting prototype can help us understand 
the scope.

Thoughts?



> Improve user-limit calculation in capacity scheduler
> ----------------------------------------------------
>
>                 Key: YARN-5889
>                 URL: https://issues.apache.org/jira/browse/YARN-5889
>             Project: Hadoop YARN
>          Issue Type: Bug
>          Components: capacity scheduler
>            Reporter: Sunil G
>            Assignee: Sunil G
>         Attachments: YARN-5889.v0.patch, YARN-5889.v1.patch, 
> YARN-5889.v2.patch
>
>
> Currently user-limit is computed during every heartbeat allocation cycle with 
> a write lock. To improve performance, this tickets is focussing on moving 
> user-limit calculation out of heartbeat allocation flow.



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

---------------------------------------------------------------------
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