RFC: Attaching threads to cgroups is OK?
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
>> 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()===================
>> 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
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