[
https://issues.apache.org/jira/browse/MAPREDUCE-4334?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13414108#comment-13414108
]
Andrew Ferguson commented on MAPREDUCE-4334:
--------------------------------------------
Arun -- I think we might be talking past each other, as we agree that both
cgroups and taskset should be available.
BTW, it turns out the sched_setaffinity() syscall does not require root if it
is applied to a process you own. Therefore, if you are running with the
DefaultContainerExecutor, you can still use sched_setaffinity, which is
excellent.
I think this is the matrix of possible use cases:
1) launch container as user & use sched_setaffinity / taskset / CPU pinning
2) launch container as user & use cgroups completely managed by Hadoop
3) launch container as user & use cgroups managed by the cluster operator
4) launch container as Hadoop & use sched_setaffinity / taskset / CPU pinning
5) launch container as Hadoop & use cgroups completely managed by Hadoop
6) launch container as Hadoop & use cgroups managed by the cluster operator
Cases 1, 2, 3 and 5 require root privs.
Cases 3 and 6 are covered by the patch above.
I'm happy to expand the LCE into a "hadoop root tool" which can be used in
cases 1, 2, 3, and 5.
In my mind, the design question is how to cover all six cases with the most
amount of code re-use.
Today, we have two important ContainerManager subsystems: the Launcher and the
Monitor. Today, reforce enforcement is entirely done within the Monitor. The
question is, where should new resource enforcement be done? I think the answer
is still "in the Monitor" even though, in some use cases, it needs access to
root privs. To get access to those privs, it can call the LCE binary (aka the
"hadoop root tool"), just as the java-side of the LCE does today.
So, concretely, this is my proposal:
- recognize the LCE binary as the "hadoop root tool"
- the LCE will have two new functionalities: 1) sched_setaffinity and 2)
creating cgroups
- in addition to the patch above, I will create 1) another pluggable
ContainersMonitor which can use these new functions (sched_setaffinity) and 2)
adapt the one above to optionally use the (creating cgroups) functionality of
the "hadoop root tool"
how does that sound?
> Add support for CPU isolation/monitoring of containers
> ------------------------------------------------------
>
> Key: MAPREDUCE-4334
> URL: https://issues.apache.org/jira/browse/MAPREDUCE-4334
> Project: Hadoop Map/Reduce
> Issue Type: Sub-task
> Reporter: Arun C Murthy
> Assignee: Andrew Ferguson
> Attachments: MAPREDUCE-4334-pre1.patch,
> MAPREDUCE-4334-pre2-with_cpu.patch, MAPREDUCE-4334-pre2.patch,
> MAPREDUCE-4334-pre3-with_cpu.patch, MAPREDUCE-4334-pre3.patch
>
>
> Once we get in MAPREDUCE-4327, it will be important to actually enforce
> limits on CPU consumption of containers.
> Several options spring to mind:
> # taskset (RHEL5+)
> # cgroups (RHEL6+)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
