Re: RFC: Attaching threads to cgroups is OK?

[Takuya Yoshikawa <yoshikawa.takuya-gVGce1chcLdL9jVzuh4AOg@public.gmane.org>]

Thank you for comments and links!

Balbir Singh wrote:
> KAMEZAWA Hiroyuki wrote:
>>> I mean, in the current implementation, threads created before the 
>>> attachement of the parent process are not treated eaqually to those 
>>> created after.
>>>
>>> Could you tell me if you know something about the rules of attachement 
>>> of pid, or tid, to cgroups? -- what ID is OK to write to "tasks" file 
>>> and what we can expect as a result?
>>>
>> Any PID is ok for "tasks". IIRC, Paul proposed "procs" file, which support
>> moving all threads of the same PIDs.
>> This mail from Paul explains some : http://lwn.net/Articles/289930/
>>
> 
> Yes, this was also discussed at the containers mini-summit
> 
> Please see
> http://groups.google.com/group/fa.linux.kernel/browse_thread/thread/ccb5e818209af143
> 

I read the discussions and understood the reasons.

>>> Tsuruta-san, how about your bio-cgroup's tracking concerning this?
>>> If we want to use your tracking functions for each threads seperately, 
>>> there seems to be a problem.
>>> ===cf. mm_get_bio_cgroup()===================
>>>            owner
>>> mm_struct ----> task_struct ----> bio_cgroup
>>> =============================================
>>> In my understanding, the mm_struct of a thread is same as its parent's.
>>> So, even if we attach the TIDs of some threads to different cgroups the 
>>> tracking always returns the same bio_cgroup -- its parent's group.
>>> Do you have some policy about in which case we can use your tracking?
>>>
>> It's will be resitriction when io-controller reuse information of the owner
>> of memory. But if it's very clear who issues I/O (by tracking read/write
>> syscall), we may have chance to record the issuer of I/O to page_cgroup
>> struct. 
> 
> We already do some tracking (at dirty time, IIRC) for task IO accounting. For
> the memory controller, tasks are virtually grouped by the mm_struct.
> 

I understand that controlling threads with their parent through the 
common mm_struct is useful and in some sense reasonable. But the 
following situation seems to me little bit confusing.

TWO POSSIBLE WAYS OF CONTROL -- after the parent process was moved
===================================================================
NEW group: [parent process]----> COMMON mm_struct
                              |
OLD group: [threads]---------+

Threads can be
1. grouped by OLD group
2. (virtually) grouped by mm_struct
    --> same as grouped by NEW group
===================================================================