Re: [PATCH 02/11] mm,migration: Do not try to migrate unmapped anonymous pages

[Minchan Kim]

On Fri, Mar 26, 2010 at 9:58 AM, KAMEZAWA Hiroyuki
<kamezawa.hiroyu@xxxxxxxxxxxxxx> wrote:
> 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 for open my eye. Kame. :)



-- 
Kind regards,
Minchan Kim
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/