systemd and cgroups: heads up

[Daniel J Walsh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 08/26/2010 02:49 PM, Dhaval Giani wrote:
> 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
Ok, then I guess sandbox and chrome-sandbox should check their current
cgroup and create a subgroup within them.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.16 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAkx2uA8ACgkQrlYvE4MpobN7pQCg0o8LqiiSfpsDv3BE2mFYR4br
S4AAnjeIh2+o1PkCBQMOkWINSsUdhjeh
=V/On
-----END PGP SIGNATURE-----