Messages in this thread | | | Date | Tue, 12 May 2009 15:21:58 +0530 | From | Balbir Singh <> | Subject | Re: [PATCH 0/3] fix stale swap cache account leak in memcg v7 |
| |
* KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> [2009-05-12 10:44:01]:
> I hope this version gets acks.. > == > As Nishimura reported, there is a race at handling swap cache. > > Typical cases are following (from Nishimura's mail) > > > == Type-1 == > If some pages of processA has been swapped out, it calls free_swap_and_cache(). > And if at the same time, processB is calling read_swap_cache_async() about > a swap entry *that is used by processA*, a race like below can happen. > > processA | processB > -------------------------------------+------------------------------------- > (free_swap_and_cache()) | (read_swap_cache_async()) > | swap_duplicate() > | __set_page_locked() > | add_to_swap_cache() > swap_entry_free() == 0 | > find_get_page() -> found | > try_lock_page() -> fail & return | > | lru_cache_add_anon() > | doesn't link this page to memcg's > | LRU, because of !PageCgroupUsed. > > This type of leak can be avoided by setting /proc/sys/vm/page-cluster to 0. > > > == Type-2 == > Assume processA is exiting and pte points to a page(!PageSwapCache). > And processB is trying reclaim the page. > > processA | processB > -------------------------------------+------------------------------------- > (page_remove_rmap()) | (shrink_page_list()) > mem_cgroup_uncharge_page() | > ->uncharged because it's not | > PageSwapCache yet. | > So, both mem/memsw.usage | > are decremented. | > | add_to_swap() -> added to swap cache. > > If this page goes thorough without being freed for some reason, this page > doesn't goes back to memcg's LRU because of !PageCgroupUsed. > > > Considering Type-1, it's better to avoid swapin-readahead when memcg is used. > swapin-readahead just read swp_entries which are near to requested entry. So, > pages not to be used can be on memory (on global LRU). When memcg is used, > this is not good behavior anyway. > > Considering Type-2, the page should be freed from SwapCache right after WriteBack. > Free swapped out pages as soon as possible is a good nature to memcg, anyway. > > The patch set includes followng > [1/3] add mem_cgroup_is_activated() function. which tell us memcg is _really_ used. > [2/3] fix swap cache handling race by avoidng readahead. > [3/3] fix swap cache handling race by check swapcount again. > > Result is good under my test.
What was the result (performance data impact) of disabling swap readahead? Otherwise, this looks the most reasonable set of patches for this problem.
-- Balbir
| |