lkml.org 
[lkml]   [2009]   [May]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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


\
 
 \ /
  Last update: 2009-05-12 11:55    [W:0.538 / U:0.468 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site