Messages in this thread | | | Date | Fri, 11 Mar 2011 12:13:43 +0900 | From | KAMEZAWA Hiroyuki <> | Subject | Re: [RFC] Storing cgroup id in page->private (Was: Re: [RFC] [PATCH 0/6] Provide cgroup isolation for buffered writes.) |
| |
On Thu, 10 Mar 2011 22:15:04 -0500 Vivek Goyal <vgoyal@redhat.com> wrote:
> On Fri, Mar 11, 2011 at 11:52:35AM +0900, KAMEZAWA Hiroyuki wrote: > > On Thu, 10 Mar 2011 21:15:31 -0500 > > Vivek Goyal <vgoyal@redhat.com> wrote: > > > > > > IMO, if you really need some per-page information, then just put it > > > > in the struct page - you can't hide the memory overhead just by > > > > having the filesystem to store it for you. That just adds > > > > unnecessary complexity... > > > > > > Ok. I guess adding anything to struct page is going to be hard and > > > we might have to fall back to looking into using page_cgroup for > > > tracking page state. I was trying to explore the ways so that we don't > > > have to instantiate whole page_cgroup structure just for trying > > > to figure out who dirtied the page. > > > > > > > Is this bad ? > > == > > Sounds like an interesting idea. I am primarily concered about the radix > tree node size increase. Not sure how big a concern this is. > > Also tracking is useful for two things. > > - Proportinal IO > - IO throttling > > For proportional IO, anyway we have to use it with memory controller to > control per cgroup dirty ratio so storing info in page_cgroup should > not hurt. >
dirty-ratio for memcg will be implemented. It's definitely necessary.
> The only other case where dependence on page_cgroup hurts is IO throttling > where IO controller does not really need memory cgroup controller (I hope > so). But we are still not sure if throttling IO at device level is a > good idea and how to resolve issues related to priority inversion. > Yes, that's priority inversion is my concern.
Thanks, -Kame
| |