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 =================================================================== _______________________________________________ Virtualization mailing list Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/virtualization
