[PATCH] Unused check for thread group leader inmem_cgroup_move_task

[KAMEZAWA Hiroyuki]

Balbir Singh said:
>> On Mon, 1 Dec 2008 09:51:35 +0530
>> Nikanth Karthikesan <knikanth at suse.de> 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 at jp.fujitsu.com>
>>
>> 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