On Fri, 26 Mar 2010 00:29:01 +0900
Minchan Kim <minchan.kim@xxxxxxxxx> wrote:
> Hi, Kame.
<snip>
> Which case do we have PageAnon && (page_mapcount == 0) && PageSwapCache ?
> With looking over code which add_to_swap_cache, I found somewhere.
>
> 1) shrink_page_list
> I think this case doesn't matter by isolate_lru_xxx.
>
> 2) shmem_swapin
> It seems to be !PageAnon
>
> 3) shmem_writepage
> It seems to be !PageAnon.
>
> 4) do_swap_page
> page_add_anon_rmap increases _mapcount before setting page->mapping to anon_vma.
> So It doesn't matter.
>
>
> I think following codes in unmap_and_move seems to handle 3) case.
>
> ---
> * Corner case handling:
> * 1. When a new swap-cache page is read into, it is added to the LRU
> * and treated as swapcache but it has no rmap yet.
> ...
> if (!page->mapping) {
> if (!PageAnon(page) && page_has_private(page)) {
> ....
> }
> goto skip_unmap;
> }
>
> ---
>
> Do we really check PageSwapCache in there?
> Do I miss any case?
>
When a page is fully unmapped, page->mapping is not cleared.
from rmap.c
==
734 void page_remove_rmap(struct page *page)
735 {
....
758 /*
759 * It would be tidy to reset the PageAnon mapping here,
760 * but that might overwrite a racing page_add_anon_rmap
761 * which increments mapcount after us but sets mapping
762 * before us: so leave the reset to free_hot_cold_page,
763 * and remember that it's only reliable while mapped.
764 * Leaving it set also helps swapoff to reinstate ptes
765 * faster for those pages still in swapcache.
766 */
767 }
==
What happens at memory reclaim is...
the first vmscan
1. isolate a page from LRU.
2. add_to_swap_cache it.
3. try_to_unmap it
4. pageout it (PG_reclaim && PG_writeback)
5. move page to the tail of LRU.
.....<after some time>
6. I/O ends and PG_writeback is cleared.
Here, in above cycle, the page is not freed. Still in LRU list.
next vmscan
7. isolate a page from LRU.
8. finds a unmapped clean SwapCache
9. drop it.
So, to _free_ unmapped SwapCache, sequence 7-9 should happen.
If enough memory is freed by the first itelation of vmscan before I/O end,
next vmscan doesn't happen. Then, we have "unmmaped clean Swapcache which has
anon_vma pointer on page->mapping" on LRU.
Thanks,
-Kame
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxxx For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>