On 5/2/14, Tejun Heo <tj@xxxxxxxxxx> wrote: > Hello, > > On Wed, Apr 30, 2014 at 04:27:51PM +0530, Raghavendra KT wrote: [...] >> Because all the way along, though we have freedom to make the cpusets >> exclusive and move tasks (say VMs) into them, >> making sure they do not interfere with each other, we can not prevent >> the other tasks spawned in a system eating into cpus of >> exclusive cpuset since they go to root automatically. > > I believe the right thing to do would be starting / confining other > tasks in the appropriate non-root cgroups. cgroup already provides > mechanisms to achieve that. The rest is upto userland. > Thanks Tejun for the reply. I agree. >> Do you think having a knob, to make sure new tasks spawned go to say a >> default directory under root makes sense? >> >> I understand that we could easily have a userspace script which could >> achieve intended goal, but kernel solution >> would really make the exclusive cpusets have exclusive access to cpus >> it should have. > > This would just be a more reliable implementation of an ad-hoc > mechanism when it can already be properly achieved by managing cgroups > of all processes in the system. Correct. Perhaps your answer clears my dilemma to go for a userspace since I donot have any strong reason except convenience to go for a kernel solution. _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/containers
