On Fri 11-03-16 10:41:18, Tejun Heo wrote: > Hello, > > This patchset extends cgroup v2 to support rgroup (resource group) for > in-process hierarchical resource control and implements PRIO_RGRP for > setpriority(2) on top to allow in-process hierarchical CPU cycle > control in a seamless way. > > cgroup v1 allowed putting threads of a process in different cgroups > which enabled ad-hoc in-process resource control of some resources. > Unfortunately, this approach was fraught with problems such as > membership ambiguity with per-process resources [Sorry if this has been already discussed, I haven't followed all the discussions regarding this topic] While I agree that per-thread granularity is no fun for controllers which operate on different than task_struct entities (like memory cgroup controller) but I am afraid that all the complications will not go away if we are strictly per-process anyway. For example memcg controller is not strictly per-process either, it operates on the mm_struct and that might be shared between different _processes_. So we still might end up in the same schizophrenic situation where two different processes are living in different cgroups while one of them is silently operating in a different memcg cgroup. I really hate this but this is what our clone(CLONE_VM) (without CLONE_THREAD) allows to do. I do not know about other controllers, maybe only memcg is so special, but that would suggest that even process-only restriction might turn out to be a problem in the future and controllers would have to face the same problem later on. Now I have to admit I do not have great ideas how to cover all the possible cases but wouldn't it make more sense to allow for more flexibility and allow thread migration while the migration can be vetoed by any controller should it cross into a different/incompatible cgroup. [...] Thanks! -- Michal Hocko SUSE Labs -- To unsubscribe from this list: send the line "unsubscribe cgroups" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
