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/ > > 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. Thanks, -Kame > Thanks, > -- Takuya Yoshikawa > _______________________________________________ > Containers mailing list > Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx > https://lists.linux-foundation.org/mailman/listinfo/containers > _______________________________________________ Virtualization mailing list Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/virtualization
