On Wed, Jul 23, 2014 at 05:19:09PM +0200, Michal Hocko wrote: > On Wed 23-07-14 11:06:08, Johannes Weiner wrote: > > On Wed, Jul 23, 2014 at 04:38:47PM +0200, Michal Hocko wrote: > [...] > > > OK, thanks for the clarification. I had this feeling but couldn't wrap > > > my head around the indirection of the code. > > > > > > It seems that checkig PageCgroupUsed(new) and bail out early in > > > mem_cgroup_migrate should just work, no? > > > > If the new page is already charged as page cache, we could just drop > > the call to mem_cgroup_migrate() altogether. > > Yeah, it is just that we do not want to do all the > page->page_cgroup->PageCgroupUsed thing in replace_page_cache_page. If the new page is *always* already charged as cache, there is no reason to even check PageCgroupUsed. We wouldn't have to do anything at this point. The old code had to, because pages were uncharged during truncation, but now we could just carry the original charge across truncation and the re-use as replacement page, and then uncharge the old page. No migration necessary. That's why I'm asking if newpage is always charged truncated page cache, or whether it can be something else. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>