RFC: Attaching threads to cgroups is OK?

Balbir Singh balbir at linux.vnet.ibm.com
Tue Aug 19 05:27:29 PDT 2008

KAMEZAWA Hiroyuki wrote:
> On Tue, 19 Aug 2008 19:38:14 +0900
> Takuya Yoshikawa <yoshikawa.takuya at oss.ntt.co.jp> wrote:
>> Hi everyone,
>> I have a question about cgroup's policy concerning the treatment of 
>> threads. Please consider that we want to attach an application which has 
>> some threads already to a certain cgroup. If we echo the pid of this 
>> application to the "tasks" file connected to this cgroup the threads 
>> belonging to this application will NOT be moved to the new group. Is it 
>> right? If so, is it OK?
> Added Paul and Balbir to CC:.
> I think it is OK ...means it works as designed
> (now, see below about future.)
>> 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

>> 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.


More information about the Containers mailing list