On Fri, Jan 29, 2016 at 06:19:31PM -0500, Johannes Weiner wrote: > Changing a page's memcg association complicates dealing with the page, > so we want to limit this as much as possible. Page migration e.g. does > not have to do that. Just like page cache replacement, it can forcibly > charge a replacement page, and then uncharge the old page when it gets > freed. Temporarily overcharging the cgroup by a single page is not an > issue in practice, and charging is so cheap nowadays that this is much > preferrable to the headache of messing with live pages. > > The only place that still changes the page->mem_cgroup binding of live > pages is when pages move along with a task to another cgroup. But that > path isolates the page from the LRU, takes the page lock, and the move > lock (lock_page_memcg()). That means page->mem_cgroup is always stable > in callers that have the page isolated from the LRU or locked. Lighter > unlocked paths, like writeback accounting, can use lock_page_memcg(). > > Signed-off-by: Johannes Weiner <hannes@xxxxxxxxxxx> Acked-by: Vladimir Davydov <vdavydov@xxxxxxxxxxxxx> -- To unsubscribe from this list: send the line "unsubscribe cgroups" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
