[
https://issues.apache.org/jira/browse/MESOS-5894?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christopher Hunt updated MESOS-5894:
------------------------------------
Description:
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
was:
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 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 limits 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
> 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
> Priority: Minor
> 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)
