From: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> To: Minchan Kim <minchan.kim@gmail.com> Cc: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>, Mel Gorman <mel@csn.ul.ie>, Andrew Morton <akpm@linux-foundation.org>, Andrea Arcangeli <aarcange@redhat.com>, Christoph Lameter <cl@linux-foundation.org>, Adam Litke <agl@us.ibm.com>, Avi Kivity <avi@redhat.com>, David Rientjes <rientjes@google.com>, Rik van Riel <riel@redhat.com>, linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: Re: [PATCH 02/11] mm,migration: Do not try to migrate unmapped anonymous pages Date: Fri, 26 Mar 2010 09:58:25 +0900 [thread overview] Message-ID: <20100326095825.69fd63a9.kamezawa.hiroyu@jp.fujitsu.com> (raw) In-Reply-To: <1269530941.1814.21.camel@barrios-desktop> On Fri, 26 Mar 2010 00:29:01 +0900 Minchan Kim <minchan.kim@gmail.com> 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
WARNING: multiple messages have this Message-ID (diff)
From: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> To: Minchan Kim <minchan.kim@gmail.com> Cc: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>, Mel Gorman <mel@csn.ul.ie>, Andrew Morton <akpm@linux-foundation.org>, Andrea Arcangeli <aarcange@redhat.com>, Christoph Lameter <cl@linux-foundation.org>, Adam Litke <agl@us.ibm.com>, Avi Kivity <avi@redhat.com>, David Rientjes <rientjes@google.com>, Rik van Riel <riel@redhat.com>, linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: Re: [PATCH 02/11] mm,migration: Do not try to migrate unmapped anonymous pages Date: Fri, 26 Mar 2010 09:58:25 +0900 [thread overview] Message-ID: <20100326095825.69fd63a9.kamezawa.hiroyu@jp.fujitsu.com> (raw) In-Reply-To: <1269530941.1814.21.camel@barrios-desktop> On Fri, 26 Mar 2010 00:29:01 +0900 Minchan Kim <minchan.kim@gmail.com> 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@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2010-03-26 1:02 UTC|newest] Thread overview: 218+ messages / expand[flat|nested] mbox.gz Atom feed top 2010-03-12 16:41 [PATCH 0/11] Memory Compaction v4 Mel Gorman 2010-03-12 16:41 ` Mel Gorman 2010-03-12 16:41 ` [PATCH 01/11] mm,migration: Take a reference to the anon_vma before migrating Mel Gorman 2010-03-12 16:41 ` Mel Gorman 2010-03-14 15:01 ` Minchan Kim 2010-03-14 15:01 ` Minchan Kim 2010-03-15 5:06 ` KAMEZAWA Hiroyuki 2010-03-15 5:06 ` KAMEZAWA Hiroyuki 2010-03-17 1:44 ` KOSAKI Motohiro 2010-03-17 1:44 ` KOSAKI Motohiro 2010-03-17 11:45 ` Mel Gorman 2010-03-17 11:45 ` Mel Gorman 2010-03-17 16:38 ` Christoph Lameter 2010-03-17 16:38 ` Christoph Lameter 2010-03-18 11:12 ` Mel Gorman 2010-03-18 11:12 ` Mel Gorman 2010-03-18 16:31 ` Christoph Lameter 2010-03-18 16:31 ` Christoph Lameter 2010-03-12 16:41 ` [PATCH 02/11] mm,migration: Do not try to migrate unmapped anonymous pages Mel Gorman 2010-03-12 16:41 ` Mel Gorman 2010-03-15 0:28 ` Minchan Kim 2010-03-15 0:28 ` Minchan Kim 2010-03-15 5:34 ` KAMEZAWA Hiroyuki 2010-03-15 5:34 ` KAMEZAWA Hiroyuki 2010-03-15 6:28 ` Minchan Kim 2010-03-15 6:28 ` Minchan Kim 2010-03-15 6:44 ` KAMEZAWA Hiroyuki 2010-03-15 6:44 ` KAMEZAWA Hiroyuki 2010-03-15 7:09 ` KAMEZAWA Hiroyuki 2010-03-15 7:09 ` KAMEZAWA Hiroyuki 2010-03-15 13:48 ` Minchan Kim 2010-03-15 13:48 ` Minchan Kim 2010-03-15 7:11 ` Minchan Kim 2010-03-15 7:11 ` Minchan Kim 2010-03-15 11:28 ` Mel Gorman 2010-03-15 11:28 ` Mel Gorman 2010-03-15 12:48 ` Minchan Kim 2010-03-15 12:48 ` Minchan Kim 2010-03-15 14:21 ` Mel Gorman 2010-03-15 14:21 ` Mel Gorman 2010-03-15 14:33 ` Minchan Kim 2010-03-15 14:33 ` Minchan Kim 2010-03-15 23:49 ` KAMEZAWA Hiroyuki 2010-03-15 23:49 ` KAMEZAWA Hiroyuki 2010-03-17 2:12 ` KAMEZAWA Hiroyuki 2010-03-17 2:12 ` KAMEZAWA Hiroyuki 2010-03-17 3:00 ` Minchan Kim 2010-03-17 3:00 ` Minchan Kim 2010-03-17 3:15 ` KAMEZAWA Hiroyuki 2010-03-17 3:15 ` KAMEZAWA Hiroyuki 2010-03-17 4:15 ` Minchan Kim 2010-03-17 4:15 ` Minchan Kim 2010-03-17 4:19 ` KAMEZAWA Hiroyuki 2010-03-17 4:19 ` KAMEZAWA Hiroyuki 2010-03-17 16:41 ` Christoph Lameter 2010-03-17 16:41 ` Christoph Lameter 2010-03-18 0:30 ` KAMEZAWA Hiroyuki 2010-03-18 0:30 ` KAMEZAWA Hiroyuki 2010-03-17 12:07 ` Mel Gorman 2010-03-17 12:07 ` Mel Gorman 2010-03-17 2:03 ` KOSAKI Motohiro 2010-03-17 2:03 ` KOSAKI Motohiro 2010-03-17 11:51 ` Mel Gorman 2010-03-17 11:51 ` Mel Gorman 2010-03-18 0:48 ` KOSAKI Motohiro 2010-03-18 0:48 ` KOSAKI Motohiro 2010-03-18 11:14 ` Mel Gorman 2010-03-18 11:14 ` Mel Gorman 2010-03-19 6:21 ` KOSAKI Motohiro 2010-03-19 6:21 ` KOSAKI Motohiro 2010-03-19 8:59 ` Mel Gorman 2010-03-19 8:59 ` Mel Gorman 2010-03-25 2:49 ` KOSAKI Motohiro 2010-03-25 2:49 ` KOSAKI Motohiro 2010-03-25 8:32 ` Mel Gorman 2010-03-25 8:32 ` Mel Gorman 2010-03-25 8:56 ` KOSAKI Motohiro 2010-03-25 8:56 ` KOSAKI Motohiro 2010-03-25 9:18 ` Mel Gorman 2010-03-25 9:18 ` Mel Gorman 2010-03-25 9:02 ` KAMEZAWA Hiroyuki 2010-03-25 9:02 ` KAMEZAWA Hiroyuki 2010-03-25 9:09 ` KOSAKI Motohiro 2010-03-25 9:09 ` KOSAKI Motohiro 2010-03-25 9:08 ` KAMEZAWA Hiroyuki 2010-03-25 9:08 ` KAMEZAWA Hiroyuki 2010-03-25 9:21 ` Mel Gorman 2010-03-25 9:21 ` Mel Gorman 2010-03-25 9:41 ` KAMEZAWA Hiroyuki 2010-03-25 9:41 ` KAMEZAWA Hiroyuki 2010-03-25 9:59 ` KOSAKI Motohiro 2010-03-25 9:59 ` KOSAKI Motohiro 2010-03-25 10:12 ` KAMEZAWA Hiroyuki 2010-03-25 10:12 ` KAMEZAWA Hiroyuki 2010-03-25 13:39 ` Mel Gorman 2010-03-25 13:39 ` Mel Gorman 2010-03-26 3:07 ` KOSAKI Motohiro 2010-03-26 3:07 ` KOSAKI Motohiro 2010-03-26 13:49 ` Mel Gorman 2010-03-26 13:49 ` Mel Gorman 2010-03-25 15:29 ` Minchan Kim 2010-03-25 15:29 ` Minchan Kim 2010-03-26 0:58 ` KAMEZAWA Hiroyuki [this message] 2010-03-26 0:58 ` KAMEZAWA Hiroyuki 2010-03-26 1:39 ` Minchan Kim 2010-03-26 1:39 ` Minchan Kim 2010-03-25 14:35 ` Christoph Lameter 2010-03-25 14:35 ` Christoph Lameter 2010-03-25 16:16 ` Minchan Kim 2010-03-25 16:16 ` Minchan Kim 2010-03-12 16:41 ` [PATCH 03/11] mm: Share the anon_vma ref counts between KSM and page migration Mel Gorman 2010-03-12 16:41 ` Mel Gorman 2010-03-12 17:14 ` Rik van Riel 2010-03-12 17:14 ` Rik van Riel 2010-03-15 5:35 ` KAMEZAWA Hiroyuki 2010-03-15 5:35 ` KAMEZAWA Hiroyuki 2010-03-17 2:06 ` KOSAKI Motohiro 2010-03-17 2:06 ` KOSAKI Motohiro 2010-03-12 16:41 ` [PATCH 04/11] Allow CONFIG_MIGRATION to be set without CONFIG_NUMA or memory hot-remove Mel Gorman 2010-03-12 16:41 ` Mel Gorman 2010-03-17 2:28 ` KOSAKI Motohiro 2010-03-17 2:28 ` KOSAKI Motohiro 2010-03-17 11:32 ` Mel Gorman 2010-03-17 11:32 ` Mel Gorman 2010-03-17 16:37 ` Christoph Lameter 2010-03-17 16:37 ` Christoph Lameter 2010-03-17 23:56 ` KOSAKI Motohiro 2010-03-17 23:56 ` KOSAKI Motohiro 2010-03-18 11:24 ` Mel Gorman 2010-03-18 11:24 ` Mel Gorman 2010-03-19 6:21 ` KOSAKI Motohiro 2010-03-19 6:21 ` KOSAKI Motohiro 2010-03-19 10:16 ` Mel Gorman 2010-03-19 10:16 ` Mel Gorman 2010-03-25 3:28 ` KOSAKI Motohiro 2010-03-25 3:28 ` KOSAKI Motohiro 2010-03-12 16:41 ` [PATCH 05/11] Export unusable free space index via /proc/unusable_index Mel Gorman 2010-03-12 16:41 ` Mel Gorman 2010-03-15 5:41 ` KAMEZAWA Hiroyuki 2010-03-15 5:41 ` KAMEZAWA Hiroyuki 2010-03-15 9:48 ` Mel Gorman 2010-03-15 9:48 ` Mel Gorman 2010-03-17 2:42 ` KOSAKI Motohiro 2010-03-17 2:42 ` KOSAKI Motohiro 2010-03-12 16:41 ` [PATCH 06/11] Export fragmentation index via /proc/extfrag_index Mel Gorman 2010-03-12 16:41 ` Mel Gorman 2010-03-17 2:49 ` KOSAKI Motohiro 2010-03-17 2:49 ` KOSAKI Motohiro 2010-03-17 11:33 ` Mel Gorman 2010-03-17 11:33 ` Mel Gorman 2010-03-23 0:22 ` KOSAKI Motohiro 2010-03-23 0:22 ` KOSAKI Motohiro 2010-03-23 12:03 ` Mel Gorman 2010-03-23 12:03 ` Mel Gorman 2010-03-25 2:47 ` KOSAKI Motohiro 2010-03-25 2:47 ` KOSAKI Motohiro 2010-03-25 8:47 ` Mel Gorman 2010-03-25 8:47 ` Mel Gorman 2010-03-25 11:20 ` KOSAKI Motohiro 2010-03-25 11:20 ` KOSAKI Motohiro 2010-03-25 14:11 ` Mel Gorman 2010-03-25 14:11 ` Mel Gorman 2010-03-26 3:10 ` KOSAKI Motohiro 2010-03-26 3:10 ` KOSAKI Motohiro 2010-03-12 16:41 ` [PATCH 07/11] Memory compaction core Mel Gorman 2010-03-12 16:41 ` Mel Gorman 2010-03-15 13:44 ` Minchan Kim 2010-03-15 13:44 ` Minchan Kim 2010-03-15 14:41 ` Mel Gorman 2010-03-15 14:41 ` Mel Gorman 2010-03-17 10:31 ` KOSAKI Motohiro 2010-03-17 10:31 ` KOSAKI Motohiro 2010-03-17 11:40 ` Mel Gorman 2010-03-17 11:40 ` Mel Gorman 2010-03-18 2:35 ` KOSAKI Motohiro 2010-03-18 2:35 ` KOSAKI Motohiro 2010-03-18 11:43 ` Mel Gorman 2010-03-18 11:43 ` Mel Gorman 2010-03-19 6:21 ` KOSAKI Motohiro 2010-03-19 6:21 ` KOSAKI Motohiro 2010-03-18 17:08 ` Mel Gorman 2010-03-18 17:08 ` Mel Gorman 2010-03-12 16:41 ` [PATCH 08/11] Add /proc trigger for memory compaction Mel Gorman 2010-03-12 16:41 ` Mel Gorman 2010-03-17 3:18 ` KOSAKI Motohiro 2010-03-17 3:18 ` KOSAKI Motohiro 2010-03-12 16:41 ` [PATCH 09/11] Add /sys trigger for per-node " Mel Gorman 2010-03-12 16:41 ` Mel Gorman 2010-03-17 3:18 ` KOSAKI Motohiro 2010-03-17 3:18 ` KOSAKI Motohiro 2010-03-12 16:41 ` [PATCH 10/11] Direct compact when a high-order allocation fails Mel Gorman 2010-03-12 16:41 ` Mel Gorman 2010-03-16 2:47 ` Minchan Kim 2010-03-16 2:47 ` Minchan Kim 2010-03-19 6:21 ` KOSAKI Motohiro 2010-03-19 6:21 ` KOSAKI Motohiro 2010-03-19 6:31 ` KOSAKI Motohiro 2010-03-19 6:31 ` KOSAKI Motohiro 2010-03-19 10:10 ` Mel Gorman 2010-03-19 10:10 ` Mel Gorman 2010-03-25 11:22 ` KOSAKI Motohiro 2010-03-25 11:22 ` KOSAKI Motohiro 2010-03-19 10:09 ` Mel Gorman 2010-03-19 10:09 ` Mel Gorman 2010-03-25 11:08 ` KOSAKI Motohiro 2010-03-25 11:08 ` KOSAKI Motohiro 2010-03-25 15:11 ` Mel Gorman 2010-03-25 15:11 ` Mel Gorman 2010-03-26 6:01 ` KOSAKI Motohiro 2010-03-26 6:01 ` KOSAKI Motohiro 2010-03-12 16:41 ` [PATCH 11/11] Do not compact within a preferred zone after a compaction failure Mel Gorman 2010-03-12 16:41 ` Mel Gorman 2010-03-23 12:25 [PATCH 0/11] Memory Compaction v5 Mel Gorman 2010-03-23 12:25 ` [PATCH 02/11] mm,migration: Do not try to migrate unmapped anonymous pages Mel Gorman 2010-03-23 12:25 ` Mel Gorman 2010-03-23 17:22 ` Christoph Lameter 2010-03-23 17:22 ` Christoph Lameter 2010-03-23 18:04 ` Mel Gorman 2010-03-23 18:04 ` Mel Gorman
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20100326095825.69fd63a9.kamezawa.hiroyu@jp.fujitsu.com \ --to=kamezawa.hiroyu@jp.fujitsu.com \ --cc=aarcange@redhat.com \ --cc=agl@us.ibm.com \ --cc=akpm@linux-foundation.org \ --cc=avi@redhat.com \ --cc=cl@linux-foundation.org \ --cc=kosaki.motohiro@jp.fujitsu.com \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-mm@kvack.org \ --cc=mel@csn.ul.ie \ --cc=minchan.kim@gmail.com \ --cc=riel@redhat.com \ --cc=rientjes@google.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.