KAMEZAWA Hiroyuki wrote: > On Tue, 19 Aug 2008 19:38:14 +0900 > Takuya Yoshikawa <yoshikawa.takuya@xxxxxxxxxxxxx> 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 http://groups.google.com/group/fa.linux.kernel/browse_thread/thread/ccb5e818209af143 > >> 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. -- Balbir _______________________________________________ Virtualization mailing list Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/virtualization
