hadoop-yarn-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Junping Du (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (YARN-311) Dynamic node resource configuration: core scheduler changes
Date Tue, 29 Oct 2013 14:31:37 GMT

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

Junping Du commented on YARN-311:
---------------------------------

Hi Luke, Thanks for comments. 
bq. 1.Requiring RMNode lock at usage site is brittle and error-prone.
Agree. How about we put write/read lock inside method like other methods currently in RMNodeImpl?
bq. 2.Extra RMNode lock per heartbeat could be expensive.
With my answer to 1, it is just read lock and it is already to be granted in heartbeat behavior,
i.e., checking if it is "fresh" heartbeat.
bq. We can even preserve the consistency without locks by using a ResourceConfig object which
holds the resource and timeout together.
IMO, It involve more complexity for creating a new object as we should put it over wire so
new protocol buf object is created as well...
How about we just keep it simple with read/write lock just like other methods in RMNodeImpl
today?

> Dynamic node resource configuration: core scheduler changes
> -----------------------------------------------------------
>
>                 Key: YARN-311
>                 URL: https://issues.apache.org/jira/browse/YARN-311
>             Project: Hadoop YARN
>          Issue Type: Sub-task
>          Components: resourcemanager, scheduler
>            Reporter: Junping Du
>            Assignee: Junping Du
>         Attachments: YARN-311-v10.patch, YARN-311-v1.patch, YARN-311-v2.patch, YARN-311-v3.patch,
YARN-311-v4.patch, YARN-311-v4.patch, YARN-311-v5.patch, YARN-311-v6.1.patch, YARN-311-v6.2.patch,
YARN-311-v6.patch, YARN-311-v7.patch, YARN-311-v8.patch, YARN-311-v9.patch
>
>
> As the first step, we go for resource change on RM side and expose admin APIs (admin
protocol, CLI, REST and JMX API) later. In this jira, we will only contain changes in scheduler.

> The flow to update node's resource and awareness in resource scheduling is: 
> 1. Resource update is through admin API to RM and take effect on RMNodeImpl.
> 2. When next NM heartbeat for updating status comes, the RMNode's resource change will
be aware and the delta resource is added to schedulerNode's availableResource before actual
scheduling happens.
> 3. Scheduler do resource allocation according to new availableResource in SchedulerNode.
> For more design details, please refer proposal and discussions in parent JIRA: YARN-291.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

Mime
View raw message