On Thu, 10 Mar 2011 22:15:04 -0500 Vivek Goyal <vgoyal@xxxxxxxxxx> 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@xxxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
