[Devel] Re: RFC: Attaching threads to cgroups is OK?
Hirokazu Takahashi
taka at valinux.co.jp
Wed Aug 20 04:48:32 PDT 2008
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.
_______________________________________________
Containers mailing list
Containers at lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/containers
More information about the Devel
mailing list