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

Christopher Hunt commented on MESOS-5894:
-----------------------------------------

Isn't it that Mesos uses *both* cpu counting *and* cgroup cpu.shares? This is 
the point that I'm making here i.e. that Mesos should provide the opportunity 
of distinguishing between the two when declaring the resource requirements of a 
task. By cpu counting, my understanding is that a 4 cpu machine will have 3.9 
cpus left given a task requirement of 0.1.

> 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)

Reply via email to