systemd and cgroups: heads up

Dhaval Giani dhaval.lists at thegianis.in
Thu Aug 26 18:49:16 UTC 2010


On Thu, Aug 26, 2010 at 8:44 PM, Daniel J Walsh <dwalsh at redhat.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 08/26/2010 01:18 PM, Daniel P. Berrange wrote:
>> On Thu, Aug 26, 2010 at 01:04:33PM -0400, Daniel J Walsh wrote:
>>>
>>> I don't know.  My goal with sandbox was to allow users to startup
>>> sandboxes in such a way that they could be still killed.
>>>
>>> Is there a way in cgroups to say
>>>
>>> dwalsh gets 80% CPU
>>> Then allow dwalsh to specify sandboxes can only use 80% of His CPU.  So
>>> he can kill them.
>>
>> You can't directly specify absolute CPU%. You can only set relative
>> prioritization between groups via the 'cpu_shares' tunable. A group
>> with double the 'cpu_shares' value will get twice as much running
>> time from the schedular. If you know all groups at a particular
>> level of the hierarchy you can calculate the relative shares
>> required to give the absolute 80% value, but it gets increasingly
>> "fun" to calculate as you add more groups/shares :-)
>>
>> eg with 2 cgroups
>>
>>  group1:  cpu_shares=1024  (20%)
>>  group2:  cpu_shares=4096  (80%)
>>
>> With 3 groups
>>
>>  group1:  cpu_shares=512  (10%)
>>  group2:  cpu_shares=512  (10%)
>>  group3:  cpu_shares=4096  (80%)
>>
>> Or with 3 groups
>>
>>  group1:  cpu_shares=342  (6.66%)
>>  group1:  cpu_shares=682  (13.34%)
>>  group2:  cpu_shares=4096 (80%)
>>
>>
>>
>> Regards,
>> Daniel
>
> Seems we have a new hammer and everyone is looking to use.  So far
> systemd, sandbox, libvirt and chrome-sandbox are using it.  Which
> probably is not going to get the results we want.
>
> Since systemd goal might be to make sure no user uses more then X% of
> memory/CPU/ or setup CPU afinity.  But sandbox and chrome-sandbox might
> allow you to use more.
>

As Daniel Berrange has stated, you cannot do X% of CPU yet for fair
scheduling. I think the feature is under development, but it will be
sometime before it hits upstream.

> Which is why I think the kernel needs to allow nesting of cgroups.

The kernel already allows nesting of cgroups.

Dhaval


More information about the devel mailing list