Hi, > > 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. This might be slightly different topic though, I've been thinking where we should add hooks to track I/O reqeust. I think the following set of hooks is enough whether we are going to support thread based cgroup or not. Hook-1: called when allocating a page, where the memory controller already have a hoook. Hook-2: called when making a page in page-cache dirty. For anonymous pages, Hook-1 is enough to track any type of I/O request. For pages in page-cache, Hook-1 is also enough for read I/O because the I/O is issued just once right after allocting the page. For write I/O requests to pages in page-cache, Hook-1 will be okay in most cases but sometimes process in another cgroup may write the pages. In this case, Hook-2 is needed to keep accurate to track I/O requests. So, it won't be hard to make bio-cgroup accurate for I/O request tracking. I'm off untill 28th, thank you, Hirokazu Takahashi. _______________________________________________ Virtualization mailing list Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/virtualization