Balbir Singh said: >> On Mon, 1 Dec 2008 09:51:35 +0530 >> Nikanth Karthikesan <knikanth@xxxxxxx> wrote: >> >> > Ok. Then should we remove the unused code which simply checks for >> thread group >> > leader but does nothing? >> > >> > Thanks >> > Nikanth >> > >> Hmm, it seem that code is obsolete. thanks. >> Balbir, how do you think ? >> >> Reviewed-by: KAMEZAWA Hiroyuki <kamezawa.hiroyu@xxxxxxxxxxxxxx> >> >> Anyway we have to visit here, again. > > Sorry, I did not review this patch. The correct thing was nikanth did > at first, move this to can_attach(). Why would we allow threads to > exist in different groups, but still mark them as being accounted to > the thread group leader. > Considering following case, # mount -t cgroup none /cgroup -t memory,cpuset # mkdir /cgroup/grpA/ # echo 1 > /cgroup/grpA/memory.use_hierarchy # echo 1G > /cgroup/grpA/memory.limit_in_bytes # mkdir /cgroup/grpA/01 # mkdir /cgroup/grpA/02 limit grpA/01's cpu to 0 limit grpA/02's cpu to 1 Run multithread program under grpA and move threads to grpA/01, grpA/02 if necessary to bind cpu. Your "hierarchy" added this kind of flexibility and this is very useful. And, of course, cgroup generic interface allows per-thread group attaching. This is why I changed my mind and agreed to handle hierarchy management under the kernel. This can be an answer for use case to explain why thread-leader-check is bad ? If we add limitation as "memcgroup should be mounted without others", And, if we only allows attaching thread-group-leader, how to migrate multi-threaded program's all thread ? I'm sorry I misunderstand something. -Kame _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/containers