hadoop-yarn-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jian He (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (YARN-3361) CapacityScheduler side changes to support non-exclusive node labels
Date Tue, 07 Apr 2015 18:22:12 GMT

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

Jian He commented on YARN-3361:
-------------------------------

Some comments on my side
- should treat each limit differently for different labeled requests?  
{code}
// Otherwise, if any of the label of this node beyond queue limit, we
// cannot allocate
on this node. Consider a small epsilon here.
{code}
- Merge queue#needResource and application#needResource
- needResource -> hasPendingResourceRequest; needResource can also be simplified if pass
in partionToAllocate 
- Some methods like canAssignToThisQueue where both nodeLabels and exclusiveType are passed,
it may be simplified by passing the current partitionToAllocate to simplify the internal if/else
check.
- The following may be incorrect, as the current request may be not the AM container request,
though null == rmAppAttempt.getMasterContainer()
{code}
// AM container allocation doesn't support non-exclusive allocation to
// avoid
painful of preempt an AM container
if 
{code}

- below if/else can be avoided if passing the nodePartition into queueCapacities.getAbsoluteCapacity(nodePartition),
{code}
if (!nodePartition.equals(RMNodeLabelsManager.NO_LABEL)) {
      queueCapacity =
          Resources
              .max(resourceCalculator, clusterResource, queueCapacity,

                  Resources.multiplyAndNormalizeUp(
                      resourceCalculator,
                      labelManager.getResourceByLabel(nodePartition,
                          clusterResource),
                      queueCapacities.getAbsoluteCapacity(nodePartition),
                      minimumAllocation));
    } else {
      // else there's no label on request, just to use absolute capacity as
      // capacity for nodes without label
      queueCapacity =
          Resources.multiplyAndNormalizeUp(resourceCalculator, labelManager
                .getResourceByLabel(CommonNodeLabelsManager.NO_LABEL, clusterResource),
              queueCapacities.getAbsoluteCapacity(),
              minimumAllocation);
    }
{code}
- the second limit won’t be hit?
{code}
    if (exclusiveType == ExclusiveType.EXCLUSIVE) {
      maxUserLimit =
          Resources.multiplyAndRoundDown(queueCapacity, userLimitFactor);
    } else if (exclusiveType == ExclusiveType.NON_EXECLUSIVE) {
      maxUserLimit =
          labelManager.getResourceByLabel(nodePartition, clusterResource);
    }
{code}
- nonExclusiveSchedulingOpportunities#setCount -> add(Priority)


> CapacityScheduler side changes to support non-exclusive node labels
> -------------------------------------------------------------------
>
>                 Key: YARN-3361
>                 URL: https://issues.apache.org/jira/browse/YARN-3361
>             Project: Hadoop YARN
>          Issue Type: Sub-task
>          Components: capacityscheduler
>            Reporter: Wangda Tan
>            Assignee: Wangda Tan
>         Attachments: YARN-3361.1.patch, YARN-3361.2.patch
>
>
> According to design doc attached in YARN-3214, we need implement following logic in CapacityScheduler:
> 1) When allocate a resource request with no node-label specified, it should get preferentially
allocated to node without labels.
> 2) When there're some available resource in a node with label, they can be used by applications
with following order:
> - Applications under queues which can access the label and ask for same labeled resource.

> - Applications under queues which can access the label and ask for non-labeled resource.
> - Applications under queues cannot access the label and ask for non-labeled resource.
> 3) Expose necessary information that can be used by preemption policy to make preemption
decisions.



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

Mime
View raw message