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 00:08:34 GMT

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

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

Luke, the volatile is not enough as you cannot set capacity and overCommitTimeout in an atomic
way (even in api with two parameters). Take following example (API in you suggested way to
have two parameters in set)
{code}
void setTotalCapacity(int resource, int overCommitTimeout) {
this.resource = resource;
this.overCommitTimeout = overCommitTimeout;
}
{code}
Thread 1 finished update it to (resource1 and overCommitTimeout1), thread 2 want to update
it to (resource2, overCommitTimeout2) but when it just update resource2, another thread is
reading and may get a mixed result (resource1, overCommitTimeout2) which should never appear
in user's operation. I think putting a synchronized tag is worth it and it equals exactly
the same as put synchronized on method (even in deadlock prospective). Thoughts?

> 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