Hello, On Wed, Apr 30, 2014 at 04:27:51PM +0530, Raghavendra KT wrote: > For some controllers like cpuset, when we have exclusive_cpu is set, > what about having a knob in the cpuset controller > to move the task to non-root (when option is set). I'm doubtful. > 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. > 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. > (I also have a POC implemented for pre-unified hierarchy tree and > understand some bit of complications involved in that and > understand that we should not have complex policies in kernel for e.g. > filtering tasks based on patterns etc..). As I wrote above, I think this is something to be solved from userland. I'm very positively against adding this sort of hacky ad-hoc policies which serves one or a few use cases well while introducing possible long-term maintenance issues. Thanks. -- tejun _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/containers
