Messages in this thread Patch in this message | | | Date | Mon, 26 Dec 2011 20:35:46 +0800 | Subject | Re: Kswapd in 3.2.0-rc5 is a CPU hog | From | Hillf Danton <> |
| |
On Sun, Dec 25, 2011 at 6:21 PM, Nikolay S. <nowhere@hakkenden.ath.cx> wrote: > > Uhm.., is this patch against 3.2-rc4? I can not apply it. There's no > mem_cgroup_lru_del_list(), but void mem_cgroup_del_lru_list(). Should I > place changes there? > > And also, -rc7 is here. May the problem be addressed as part of some > ongoing work? Is there any reason to try -rc7 (the problem requires > several days of uptime to become obvious)? >
Sorry, Nikolay, it is not based on the -next, nor on the -rc5(I assumed it was). The following is based on -next, and if you want to test -rc5, please grep MEM_CGROUP_ZSTAT mm/memcontrol.c and change it.
Best regard
Hillf ---
--- a/mm/memcontrol.c Mon Dec 26 20:34:38 2011 +++ b/mm/memcontrol.c Mon Dec 26 20:37:54 2011 @@ -1076,7 +1076,11 @@ void mem_cgroup_lru_del_list(struct page VM_BUG_ON(!memcg); mz = page_cgroup_zoneinfo(memcg, page); /* huge page split is done under lru_lock. so, we have no races. */ - MEM_CGROUP_ZSTAT(mz, lru) -= 1 << compound_order(page); + if (WARN_ON_ONCE(MEM_CGROUP_ZSTAT(mz, lru) < + (1 << compound_order(page)))) + MEM_CGROUP_ZSTAT(mz, lru) = 0; + else + MEM_CGROUP_ZSTAT(mz, lru) -= 1 << compound_order(page); }
void mem_cgroup_lru_del(struct page *page)
| |