mesos-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Christopher Hunt (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (MESOS-5894) cpu.share should be considered distinctly from cpu allocation
Date Sun, 24 Jul 2016 03:38:20 GMT

     [ 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 an explicit 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.

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 an explicit means of controlling their 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.

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: cpu-usage
>
> As a framework developer I wish to explicitly declare the cpu.share for a task and its
associated executor so that I may have an explicit 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.
> Related issue: https://issues.apache.org/jira/browse/MESOS-1718



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message