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

Jason Lowe commented on YARN-2004:
----------------------------------

I'm not sure I understand the priority inversion problem and why we would be 
changing headroom.  The headroom has no priority calculations in it.  As I see 
it, the priority scheduling is _only_ changing the order in which applications 
are examined when deciding how to assign free resources in a queue.  In other 
words, it does _not_ change the following:

- the priority order between queues (i.e.: deciding which queue is first in 
line to obtain free resources in the cluster)
- the user limits within a queue (i.e.: making an app higher priority does not 
implicitly give the user more room to grow within the queue than normal)
- the headroom for an app within the queue (higher priority doesn't change the 
queue capacity or user limits)

For example, a user is running app A then follows up with app B.  The user 
decides app B is pretty important and raises its priority.  This doesn't change 
the user limits within the queue or the headroom of those apps, but it does 
change which app will be assigned a spare resource if it is available.  If the 
queue is totally full then both apps will be told their headroom is zero.  One 
(or both) of them will need to free up some resources to make progress.  When 
resources becomes available, app B will have the first chance to claim them 
since it was made a higher priority than A.

> Priority scheduling support in Capacity scheduler
> -------------------------------------------------
>
>                 Key: YARN-2004
>                 URL: https://issues.apache.org/jira/browse/YARN-2004
>             Project: Hadoop YARN
>          Issue Type: Sub-task
>          Components: capacityscheduler
>            Reporter: Sunil G
>            Assignee: Sunil G
>         Attachments: 0001-YARN-2004.patch
>
>
> Based on the priority of the application, Capacity Scheduler should be able 
> to give preference to application while doing scheduling.
> Comparator<FiCaSchedulerApp> applicationComparator can be changed as below.   
>         
> 1.    Check for Application priority. If priority is available, then return 
> the highest priority job.
> 2.    Otherwise continue with existing logic such as App ID comparison and 
> then TimeStamp comparison.



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

Reply via email to