[
https://issues.apache.org/jira/browse/MESOS-5894?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christopher Hunt updated MESOS-5894:
------------------------------------
Priority: Major (was: Minor)
> cpu share should be considered distinctly from cpu allocation
> -------------------------------------------------------------
>
> Key: MESOS-5894
> URL: https://issues.apache.org/jira/browse/MESOS-5894
> Project: Mesos
> Issue Type: Improvement
> Components: allocation
> Affects Versions: 0.28.2
> Environment: Linux, cgroups, docker
> Reporter: Christopher Hunt
> Labels: cgroups, cpu-usage, docker
>
> As a framework developer I wish to explicitly declare the cpu.share for a
> task and its associated executor so that I may have a direct means of
> controlling their respective cpu usage at runtime.
> With current behaviour, I've noticed that the cgroup cpu.share for a task
> includes both the executor's cpu.share and also the cpu value specified as a
> task's resources. The cpu.share value appears to be calculated as a multiple
> of 1024, therefore 1 cpu == 1024, 0.1 cpu = 102 and so forth. I find this
> behaviour to be unexpected, and also an overloading of the meaning of the
> resource cpu type. My understanding of the resource cpu type is that it is
> used primarily for decrementing from the total number of cpus available to a
> node, and thereby influences the resource offers made to a given framework in
> consideration of other frameworks. On the other hand, cpu shares limit the
> amount of cpu used at runtime.
> By way of a solution, perhaps a new Resource type could be introduced named
> "cpu-share" and optionally provided by a scheduler when constructing a
> TaskInfo. The cpu share resource could also be optionally specified for the
> associated executor. By not specifying the cpu share, the existing behaviour
> is preserved thereby providing backward compatibility.
> Related issue: https://issues.apache.org/jira/browse/MESOS-1718
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)