Re: [PATCH 2/2] mm: memcontrol: drop unnecessary lru locking from mem_cgroup_migrate()
From: Johannes Weiner <hidden>
Date: 2016-02-07 18:58:10
Also in:
linux-mm, lkml
On Feb 7, 2016, at 1:41 PM, Vladimir Davydov [off-list ref] wrote:quoted
On Thu, Feb 04, 2016 at 03:07:47PM -0500, Johannes Weiner wrote: Migration accounting in the memory controller used to have to handle both oldpage and newpage being on the LRU already; fuse's page cache replacement used to pass a recycled newpage that had been uncharged but not freed and removed from the LRU, and the memcg migration code used to uncharge oldpage to "pass on" the existing charge to newpage. Nowadays, pages are no longer uncharged when truncated from the page cache, but rather only at free time, so if a LRU page is recycled in page cache replacement it'll also still be charged. And we bail out of the charge transfer altogether in that case. Tell commit_charge() that we know newpage is not on the LRU, to avoid taking the zone->lru_lock unnecessarily from the migration path. But also, oldpage is no longer uncharged inside migration. We only use oldpage for its page->mem_cgroup and page size, so we don't care about its LRU state anymore either. Remove any mention from the kernel doc. Signed-off-by: Johannes Weiner <redacted> Suggested-by: Hugh Dickins <redacted>Acked-by: Vladimir Davydov <redacted>
Thanks!
quoted hunk ↗ jump to hunk
@@ -5483,6 +5483,7 @@ void mem_cgroup_migrate(struct page *oldpage, struct page *newpage) unsigned int nr_pages; bool compound; + VM_BUG_ON_PAGE(PageLRU(newpage), newpage);
That's actually possible for fuse. But in that case newpage is charged and we bail.-- To unsubscribe from this list: send the line "unsubscribe cgroups" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html