On Thu, Dec 23, 2010 at 03:38:51PM -0800, Scott Baker wrote: > I'm using util-vserver-0.30.216 on a 2.6.27 distribution. util-vserver 0.30.216 is not released (yet) and 2.6.27.x has an incomplete and partially buggy cgroups implementation (so I'd suggest to update to at least 2.6.32.x) > My questions have to do with limiting CPU use to vservers > using the cgroups mechanism. > 1) When I ssh into a particular vserver, the processes spawned > as the result of the ssh, namely a bash shell and it's resulting > subprocesses, are not associated with the cgroup of that vserver. that is a bug, everything running inside a guest (with a recent kernel/patch and proper util-vserver) will be limited by the cgroup setup as well > They remain associated with the root cgroup. > I assume this is because sshd is running as a task in the > root cgroup. ssh inside a cgroups enabled guest will be bound by the very same cgroup associated with that guest than every other process (inside that guest) > is there something I'm doing wrong or an easy way to fix this? updating to a working kernel and recent util-vserver should do the trick, for 2.6.27.x you have to patch it yourself > Alternatively I can look into patching this myself, if anyone > has any helpful pointers, please send them by. > I have a lot of jobs that get started via ssh sessions and > they're not getting the benefit of the cgroup scheduling. > 2) The next question I have is a general cgroup issue. > I would like to give one vserver exclusive use of a CPU so > that no other vserver may use that cpu. this is basically cpu-sets and can be done with 2.6.27 too, as the cpu-set mechanism there should work > The brute-force approach to do this is to set > /dev/cgroup/<vserver>/cpuset.cpus for that cpu and to remove > that cpu from the cpuset.cpus for every other vserver. > If I want to give one vserver exclusive use of a CPU, then > I need to touch the cpuset for every other vserver to remove > that CPU. Am I missing anything here? in recent kernels you can remove a cpu from 'normal' scheduling and lateron assign it to a cpuset AFAIK, so that might simplify this procedure ... best, Herbert > Thanks, > Scott