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