-----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@xxxxxxxxxx> 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----- -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
