From: Mel Gorman <mgorman@suse.de> To: Minchan Kim <minchan@kernel.org> Cc: Andrew Morton <akpm@linux-foundation.org>, Andrea Arcangeli <aarcange@redhat.com>, Minchan Kim <minchan.kim@gmail.com>, Dave Jones <davej@redhat.com>, Jan Kara <jack@suse.cz>, Andy Isaacson <adi@hexapodia.org>, Johannes Weiner <jweiner@redhat.com>, Rik van Riel <riel@redhat.com>, Nai Xia <nai.xia@gmail.com>, Linux-MM <linux-mm@kvack.org>, LKML <linux-kernel@vger.kernel.org> Subject: Re: [PATCH 11/11] mm: Isolate pages for immediate reclaim on their own LRU Date: Tue, 20 Dec 2011 09:55:44 +0000 [thread overview] Message-ID: <20111220095544.GP3487@suse.de> (raw) In-Reply-To: <20111220071026.GA19025@barrios-laptop.redhat.com> On Tue, Dec 20, 2011 at 04:10:26PM +0900, Minchan Kim wrote: > > > > * Writeback is about to end against a page which has been marked for immediate > > > > * reclaim. If it still appears to be reclaimable, move it to the tail of the > > > > * inactive list. > > > > */ > > > > void rotate_reclaimable_page(struct page *page) > > > > { > > > > + struct zone *zone = page_zone(page); > > > > + struct list_head *page_list; > > > > + struct pagevec *pvec; > > > > + unsigned long flags; > > > > + > > > > + page_cache_get(page); > > > > + local_irq_save(flags); > > > > + __mod_zone_page_state(zone, NR_IMMEDIATE, -1); > > > > + > > > > > > I am not sure underflow never happen. > > > We do SetPageReclaim at several places but dont' increase NR_IMMEDIATE. > > > > > > > In those cases, we do not move the page to the immedate list either. > > That's my concern. > We didn't move the page to immediate list but set SetPageReclaim. It means > we don't increate NR_IMMEDIATE. > If end_page_writeback have called that page, rotate_reclimable_page would be called. > Eventually, __mod_zone_page_state(zone, NR_IMMEDIATE, -1) is called. > But I didn't look into the code yet for confirming it's possbile or not. > Ah, now I see your concern. The key is that they get moved to the immediate LRU later although it is not obvious. This should be double checked but when I was implementing this, I looked at the different places that called SetPageReclaim. mm/swap.c:lru_deactivate_fn() calls SetPageReclaim but also moves the page to the immediate LRU list so no problem with accounting there. mm/vmscan.c:pageout() calls SetPageReclaim but does not move the page explicitly as such. Instead, it gets picked up by putback_lru_pages() later which checks for inactive LRU pages that are marked PageReclaim and selects the immediate LRU in this case. The counter gets incremented for the appropriate LRU list by __add_page_to_lru_list(). Even if we do have an active page with PageReclaim set, it should not cause an accounting difficulty mm/vmscan.c:shrink_page_list() calls SetPageReclaim but like pageout(), it gets picked up by putback_lru_pages() later Did I miss anything? > > During one test I was recording /proc/vmstat every 10 seconds and never > > saw an underflow. > > If it's very rare, it would be very hard to see it. > But once it happened, I would not expect it to recover. The nr_immediate value usually reads as 0. > > > > <SNIP> > > > > static void update_page_reclaim_stat(struct zone *zone, struct page *page, > > > > @@ -475,6 +532,13 @@ static void lru_deactivate_fn(struct page *page, void *arg) > > > > * is _really_ small and it's non-critical problem. > > > > */ > > > > SetPageReclaim(page); > > > > + > > > > + /* > > > > + * Move to the LRU_IMMEDIATE list to avoid being scanned > > > > + * by page reclaim uselessly. > > > > + */ > > > > + list_move_tail(&page->lru, &zone->lru[LRU_IMMEDIATE].list); > > > > + __mod_zone_page_state(zone, NR_IMMEDIATE, 1); > > > > > > It mekes below count of PGDEACTIVATE wrong in lru_deactivate_fn. > > > Before this patch, all is from active to inacive so it was right. > > > But with this patch, it can be from acdtive to immediate. > > > > > > > I do not quite understand. PGDEACTIVATE is incremented if the page was > > active and this is checked before the move to the immediate LRU. Whether > > it moves to the immediate LRU or the end of the inactive list, it is > > still a deactivation. What's wrong with incrementing the count if it > > Hmm, I have thought deactivation is only from active to deactive. This is a matter of definition really. The page is going from active to inactive. The immediate list is similar to the inactive list in this case, at least from a deactivation point of view. > I might be wrong but if we perhaps move page from active to unevictable list, > is it deactivation, too? I would consider it a deactivate if PageActive got cleared. Here we are talking about the lru_deactivate_fn function. Whether it moves to the immediate list or the end of the inactive list, the page is being deactivated. > Maybe we need consistent count. > In this case, I think we are being consistent. The page is deactivated, we increase the PFDEACTIVATE counter. Thanks very much for reviewing this closely, I appreciate it. -- Mel Gorman SUSE Labs
WARNING: multiple messages have this Message-ID (diff)
From: Mel Gorman <mgorman@suse.de> To: Minchan Kim <minchan@kernel.org> Cc: Andrew Morton <akpm@linux-foundation.org>, Andrea Arcangeli <aarcange@redhat.com>, Minchan Kim <minchan.kim@gmail.com>, Dave Jones <davej@redhat.com>, Jan Kara <jack@suse.cz>, Andy Isaacson <adi@hexapodia.org>, Johannes Weiner <jweiner@redhat.com>, Rik van Riel <riel@redhat.com>, Nai Xia <nai.xia@gmail.com>, Linux-MM <linux-mm@kvack.org>, LKML <linux-kernel@vger.kernel.org> Subject: Re: [PATCH 11/11] mm: Isolate pages for immediate reclaim on their own LRU Date: Tue, 20 Dec 2011 09:55:44 +0000 [thread overview] Message-ID: <20111220095544.GP3487@suse.de> (raw) In-Reply-To: <20111220071026.GA19025@barrios-laptop.redhat.com> On Tue, Dec 20, 2011 at 04:10:26PM +0900, Minchan Kim wrote: > > > > * Writeback is about to end against a page which has been marked for immediate > > > > * reclaim. If it still appears to be reclaimable, move it to the tail of the > > > > * inactive list. > > > > */ > > > > void rotate_reclaimable_page(struct page *page) > > > > { > > > > + struct zone *zone = page_zone(page); > > > > + struct list_head *page_list; > > > > + struct pagevec *pvec; > > > > + unsigned long flags; > > > > + > > > > + page_cache_get(page); > > > > + local_irq_save(flags); > > > > + __mod_zone_page_state(zone, NR_IMMEDIATE, -1); > > > > + > > > > > > I am not sure underflow never happen. > > > We do SetPageReclaim at several places but dont' increase NR_IMMEDIATE. > > > > > > > In those cases, we do not move the page to the immedate list either. > > That's my concern. > We didn't move the page to immediate list but set SetPageReclaim. It means > we don't increate NR_IMMEDIATE. > If end_page_writeback have called that page, rotate_reclimable_page would be called. > Eventually, __mod_zone_page_state(zone, NR_IMMEDIATE, -1) is called. > But I didn't look into the code yet for confirming it's possbile or not. > Ah, now I see your concern. The key is that they get moved to the immediate LRU later although it is not obvious. This should be double checked but when I was implementing this, I looked at the different places that called SetPageReclaim. mm/swap.c:lru_deactivate_fn() calls SetPageReclaim but also moves the page to the immediate LRU list so no problem with accounting there. mm/vmscan.c:pageout() calls SetPageReclaim but does not move the page explicitly as such. Instead, it gets picked up by putback_lru_pages() later which checks for inactive LRU pages that are marked PageReclaim and selects the immediate LRU in this case. The counter gets incremented for the appropriate LRU list by __add_page_to_lru_list(). Even if we do have an active page with PageReclaim set, it should not cause an accounting difficulty mm/vmscan.c:shrink_page_list() calls SetPageReclaim but like pageout(), it gets picked up by putback_lru_pages() later Did I miss anything? > > During one test I was recording /proc/vmstat every 10 seconds and never > > saw an underflow. > > If it's very rare, it would be very hard to see it. > But once it happened, I would not expect it to recover. The nr_immediate value usually reads as 0. > > > > <SNIP> > > > > static void update_page_reclaim_stat(struct zone *zone, struct page *page, > > > > @@ -475,6 +532,13 @@ static void lru_deactivate_fn(struct page *page, void *arg) > > > > * is _really_ small and it's non-critical problem. > > > > */ > > > > SetPageReclaim(page); > > > > + > > > > + /* > > > > + * Move to the LRU_IMMEDIATE list to avoid being scanned > > > > + * by page reclaim uselessly. > > > > + */ > > > > + list_move_tail(&page->lru, &zone->lru[LRU_IMMEDIATE].list); > > > > + __mod_zone_page_state(zone, NR_IMMEDIATE, 1); > > > > > > It mekes below count of PGDEACTIVATE wrong in lru_deactivate_fn. > > > Before this patch, all is from active to inacive so it was right. > > > But with this patch, it can be from acdtive to immediate. > > > > > > > I do not quite understand. PGDEACTIVATE is incremented if the page was > > active and this is checked before the move to the immediate LRU. Whether > > it moves to the immediate LRU or the end of the inactive list, it is > > still a deactivation. What's wrong with incrementing the count if it > > Hmm, I have thought deactivation is only from active to deactive. This is a matter of definition really. The page is going from active to inactive. The immediate list is similar to the inactive list in this case, at least from a deactivation point of view. > I might be wrong but if we perhaps move page from active to unevictable list, > is it deactivation, too? I would consider it a deactivate if PageActive got cleared. Here we are talking about the lru_deactivate_fn function. Whether it moves to the immediate list or the end of the inactive list, the page is being deactivated. > Maybe we need consistent count. > In this case, I think we are being consistent. The page is deactivated, we increase the PFDEACTIVATE counter. Thanks very much for reviewing this closely, I appreciate it. -- Mel Gorman SUSE Labs -- 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/ . Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/ Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2011-12-20 9:55 UTC|newest] Thread overview: 100+ messages / expand[flat|nested] mbox.gz Atom feed top 2011-12-14 15:41 [PATCH 0/11] Reduce compaction-related stalls and improve asynchronous migration of dirty pages v6 Mel Gorman 2011-12-14 15:41 ` Mel Gorman 2011-12-14 15:41 ` [PATCH 01/11] mm: compaction: Allow compaction to isolate dirty pages Mel Gorman 2011-12-14 15:41 ` Mel Gorman 2011-12-14 15:41 ` [PATCH 02/11] mm: compaction: Use synchronous compaction for /proc/sys/vm/compact_memory Mel Gorman 2011-12-14 15:41 ` Mel Gorman 2011-12-14 15:41 ` [PATCH 03/11] mm: vmscan: Check if we isolated a compound page during lumpy scan Mel Gorman 2011-12-14 15:41 ` Mel Gorman 2011-12-15 23:21 ` Rik van Riel 2011-12-15 23:21 ` Rik van Riel 2011-12-14 15:41 ` [PATCH 04/11] mm: vmscan: Do not OOM if aborting reclaim to start compaction Mel Gorman 2011-12-14 15:41 ` Mel Gorman 2011-12-15 23:36 ` Rik van Riel 2011-12-15 23:36 ` Rik van Riel 2011-12-14 15:41 ` [PATCH 05/11] mm: compaction: Determine if dirty pages can be migrated without blocking within ->migratepage Mel Gorman 2011-12-14 15:41 ` Mel Gorman 2011-12-16 3:32 ` Rik van Riel 2011-12-16 3:32 ` Rik van Riel 2011-12-16 23:20 ` Andrew Morton 2011-12-16 23:20 ` Andrew Morton 2011-12-17 3:03 ` Nai Xia 2011-12-17 3:03 ` Nai Xia 2011-12-17 3:26 ` Andrew Morton 2011-12-17 3:26 ` Andrew Morton 2011-12-19 11:05 ` Mel Gorman 2011-12-19 11:05 ` Mel Gorman 2011-12-19 13:12 ` nai.xia 2011-12-19 13:12 ` nai.xia 2011-12-14 15:41 ` [PATCH 06/11] mm: compaction: make isolate_lru_page() filter-aware again Mel Gorman 2011-12-14 15:41 ` Mel Gorman 2011-12-16 3:34 ` Rik van Riel 2011-12-16 3:34 ` Rik van Riel 2011-12-18 1:53 ` Minchan Kim 2011-12-18 1:53 ` Minchan Kim 2011-12-14 15:41 ` [PATCH 07/11] mm: page allocator: Do not call direct reclaim for THP allocations while compaction is deferred Mel Gorman 2011-12-14 15:41 ` Mel Gorman 2011-12-16 4:10 ` Rik van Riel 2011-12-16 4:10 ` Rik van Riel 2011-12-14 15:41 ` [PATCH 08/11] mm: compaction: Introduce sync-light migration for use by compaction Mel Gorman 2011-12-14 15:41 ` Mel Gorman 2011-12-16 4:31 ` Rik van Riel 2011-12-16 4:31 ` Rik van Riel 2011-12-18 2:05 ` Minchan Kim 2011-12-18 2:05 ` Minchan Kim 2011-12-19 11:45 ` Mel Gorman 2011-12-19 11:45 ` Mel Gorman 2011-12-20 7:18 ` Minchan Kim 2011-12-20 7:18 ` Minchan Kim 2012-01-13 21:25 ` Andrew Morton 2012-01-13 21:25 ` Andrew Morton 2012-01-16 11:33 ` Mel Gorman 2012-01-16 11:33 ` Mel Gorman 2011-12-14 15:41 ` [PATCH 09/11] mm: vmscan: When reclaiming for compaction, ensure there are sufficient free pages available Mel Gorman 2011-12-14 15:41 ` Mel Gorman 2011-12-16 4:35 ` Rik van Riel 2011-12-16 4:35 ` Rik van Riel 2011-12-14 15:41 ` [PATCH 10/11] mm: vmscan: Check if reclaim should really abort even if compaction_ready() is true for one zone Mel Gorman 2011-12-14 15:41 ` Mel Gorman 2011-12-16 4:38 ` Rik van Riel 2011-12-16 4:38 ` Rik van Riel 2011-12-16 11:29 ` Mel Gorman 2011-12-16 11:29 ` Mel Gorman 2011-12-14 15:41 ` [PATCH 11/11] mm: Isolate pages for immediate reclaim on their own LRU Mel Gorman 2011-12-14 15:41 ` Mel Gorman 2011-12-16 4:47 ` Rik van Riel 2011-12-16 4:47 ` Rik van Riel 2011-12-16 12:26 ` Mel Gorman 2011-12-16 12:26 ` Mel Gorman 2011-12-16 15:17 ` Johannes Weiner 2011-12-16 15:17 ` Johannes Weiner 2011-12-16 16:07 ` Mel Gorman 2011-12-16 16:07 ` Mel Gorman 2011-12-19 16:14 ` Johannes Weiner 2011-12-19 16:14 ` Johannes Weiner 2011-12-17 16:08 ` Minchan Kim 2011-12-17 16:08 ` Minchan Kim 2011-12-19 13:26 ` Mel Gorman 2011-12-19 13:26 ` Mel Gorman 2011-12-20 7:10 ` Minchan Kim 2011-12-20 7:10 ` Minchan Kim 2011-12-20 9:55 ` Mel Gorman [this message] 2011-12-20 9:55 ` Mel Gorman 2011-12-23 19:08 ` Hugh Dickins 2011-12-23 19:08 ` Hugh Dickins 2011-12-29 16:59 ` Mel Gorman 2011-12-29 16:59 ` Mel Gorman 2011-12-29 19:31 ` Rik van Riel 2011-12-29 19:31 ` Rik van Riel 2011-12-30 11:27 ` Mel Gorman 2011-12-30 11:27 ` Mel Gorman 2011-12-16 22:56 ` [PATCH 0/11] Reduce compaction-related stalls and improve asynchronous migration of dirty pages v6 Andrew Morton 2011-12-16 22:56 ` Andrew Morton 2011-12-19 14:40 ` Mel Gorman 2011-12-19 14:40 ` Mel Gorman 2011-12-16 23:37 ` Andrew Morton 2011-12-16 23:37 ` Andrew Morton 2011-12-19 14:20 ` Mel Gorman 2011-12-19 14:20 ` Mel Gorman -- strict thread matches above, loose matches on Subject: below -- 2011-12-01 17:36 [PATCH 0/11] Reduce compaction-related stalls and improve asynchronous migration of dirty pages v5 Mel Gorman 2011-12-01 17:36 ` [PATCH 11/11] mm: Isolate pages for immediate reclaim on their own LRU Mel Gorman 2011-12-01 17:36 ` 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=20111220095544.GP3487@suse.de \ --to=mgorman@suse.de \ --cc=aarcange@redhat.com \ --cc=adi@hexapodia.org \ --cc=akpm@linux-foundation.org \ --cc=davej@redhat.com \ --cc=jack@suse.cz \ --cc=jweiner@redhat.com \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-mm@kvack.org \ --cc=minchan.kim@gmail.com \ --cc=minchan@kernel.org \ --cc=nai.xia@gmail.com \ --cc=riel@redhat.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.