memcg: fix split_huge_page_refcounts()
authorHugh Dickins <[email protected]>
Fri, 13 Jan 2012 01:19:52 +0000 (17:19 -0800)
committerLinus Torvalds <[email protected]>
Fri, 13 Jan 2012 04:13:09 +0000 (20:13 -0800)
commit12d27107867fc7216e8faaff0b894b0f162dcf75
tree8f35d39f7e5d0b0f0ba10a3475e9fa4a2581e509
parent0cee34fd72c582b4f8ad8ce00645b75fb4168199
memcg: fix split_huge_page_refcounts()

This patch started off as a cleanup: __split_huge_page_refcounts() has to
cope with two scenarios, when the hugepage being split is already on LRU,
and when it is not; but why does it have to split that accounting across
three different sites?  Consolidate it in lru_add_page_tail(), handling
evictable and unevictable alike, and use standard add_page_to_lru_list()
when accounting is needed (when the head is not yet on LRU).

But a recent regression in -next, I guess the removal of PageCgroupAcctLRU
test from mem_cgroup_split_huge_fixup(), makes this now a necessary fix:
under load, the MEM_CGROUP_ZSTAT count was wrapping to a huge number,
messing up reclaim calculations and causing a freeze at rmdir of cgroup.

Add a VM_BUG_ON to mem_cgroup_lru_del_list() when we're about to wrap that
count - this has not been the only such incident.  Document that
lru_add_page_tail() is for Transparent HugePages by #ifdef around it.

Signed-off-by: Hugh Dickins <[email protected]>
Cc: Daisuke Nishimura <[email protected]>
Cc: KAMEZAWA Hiroyuki <[email protected]>
Cc: Johannes Weiner <[email protected]>
Cc: Michal Hocko <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
mm/huge_memory.c
mm/memcontrol.c
mm/swap.c