From: Mel Gorman <mgorman@suse.de> To: Minchan Kim <minchan@kernel.org> Cc: Linux-MM <linux-mm@kvack.org>, Rik van Riel <riel@redhat.com>, Jim Schutt <jaschut@sandia.gov>, LKML <linux-kernel@vger.kernel.org> Subject: Re: [PATCH 2/6] mm: vmscan: Scale number of pages reclaimed by reclaim/compaction based on failures Date: Wed, 8 Aug 2012 09:51:12 +0100 [thread overview] Message-ID: <20120808085112.GJ29814@suse.de> (raw) In-Reply-To: <20120808082738.GF4247@bbox> On Wed, Aug 08, 2012 at 05:27:38PM +0900, Minchan Kim wrote: > On Wed, Aug 08, 2012 at 08:55:26AM +0100, Mel Gorman wrote: > > On Wed, Aug 08, 2012 at 10:48:24AM +0900, Minchan Kim wrote: > > > Hi Mel, > > > > > > Just out of curiosity. > > > What's the problem did you see? (ie, What's the problem do this patch solve?) > > > > Everythign in this series is related to the problem in the leader - high > > order allocation success rates are lower. This patch increases the success > > rates when allocating under load. > > > > > AFAIUC, it seem to solve consecutive allocation success ratio through > > > getting several free pageblocks all at once in a process/kswapd > > > reclaim context. Right? > > > > Only pageblocks if it is order-9 on x86, it reclaims an amount that depends > > on an allocation size. This only happens during reclaim/compaction context > > when we know that a high-order allocation has recently failed. The objective > > is to reclaim enough order-0 pages so that compaction can succeed again. > > Your patch increases the number of pages to be reclaimed with considering > the number of fail case during deferring period and your test proved it's > really good. Without your patch, why can't VM reclaim enough pages? It could reclaim enough pages but it doesn't. nr_to_reclaim is SWAP_CLUSTER_MAX and that gets short-cutted in direct reclaim at least by if (sc->nr_reclaimed >= sc->nr_to_reclaim) goto out; I could set nr_to_reclaim in try_to_free_pages() of course and drive it from there but that's just different, not better. If driven from do_try_to_free_pages(), it is also possible that priorities will rise. When they reach DEF_PRIORITY-2, it will also start stalling and setting pages for immediate reclaim which is more disruptive than not desirable in this case. That is a more wide-reaching change than I would expect for this problem and could cause another regression related to THP requests causing interactive jitter. > Other processes steal the pages reclaimed? Or the page it reclaimed were in pageblocks that could not be used. > Why I ask a question is that I want to know what's the problem at current > VM. > We cannot reliably tell in advance whether compaction is going to succeed in the future without doing a full scan of the zone which would be both very heavy and race with any allocation requests. Compaction needs free pages to succeed so the intention is to scale the number of pages reclaimed with the number of recent compaction failures. -- 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: Linux-MM <linux-mm@kvack.org>, Rik van Riel <riel@redhat.com>, Jim Schutt <jaschut@sandia.gov>, LKML <linux-kernel@vger.kernel.org> Subject: Re: [PATCH 2/6] mm: vmscan: Scale number of pages reclaimed by reclaim/compaction based on failures Date: Wed, 8 Aug 2012 09:51:12 +0100 [thread overview] Message-ID: <20120808085112.GJ29814@suse.de> (raw) In-Reply-To: <20120808082738.GF4247@bbox> On Wed, Aug 08, 2012 at 05:27:38PM +0900, Minchan Kim wrote: > On Wed, Aug 08, 2012 at 08:55:26AM +0100, Mel Gorman wrote: > > On Wed, Aug 08, 2012 at 10:48:24AM +0900, Minchan Kim wrote: > > > Hi Mel, > > > > > > Just out of curiosity. > > > What's the problem did you see? (ie, What's the problem do this patch solve?) > > > > Everythign in this series is related to the problem in the leader - high > > order allocation success rates are lower. This patch increases the success > > rates when allocating under load. > > > > > AFAIUC, it seem to solve consecutive allocation success ratio through > > > getting several free pageblocks all at once in a process/kswapd > > > reclaim context. Right? > > > > Only pageblocks if it is order-9 on x86, it reclaims an amount that depends > > on an allocation size. This only happens during reclaim/compaction context > > when we know that a high-order allocation has recently failed. The objective > > is to reclaim enough order-0 pages so that compaction can succeed again. > > Your patch increases the number of pages to be reclaimed with considering > the number of fail case during deferring period and your test proved it's > really good. Without your patch, why can't VM reclaim enough pages? It could reclaim enough pages but it doesn't. nr_to_reclaim is SWAP_CLUSTER_MAX and that gets short-cutted in direct reclaim at least by if (sc->nr_reclaimed >= sc->nr_to_reclaim) goto out; I could set nr_to_reclaim in try_to_free_pages() of course and drive it from there but that's just different, not better. If driven from do_try_to_free_pages(), it is also possible that priorities will rise. When they reach DEF_PRIORITY-2, it will also start stalling and setting pages for immediate reclaim which is more disruptive than not desirable in this case. That is a more wide-reaching change than I would expect for this problem and could cause another regression related to THP requests causing interactive jitter. > Other processes steal the pages reclaimed? Or the page it reclaimed were in pageblocks that could not be used. > Why I ask a question is that I want to know what's the problem at current > VM. > We cannot reliably tell in advance whether compaction is going to succeed in the future without doing a full scan of the zone which would be both very heavy and race with any allocation requests. Compaction needs free pages to succeed so the intention is to scale the number of pages reclaimed with the number of recent compaction failures. -- 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/ . Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2012-08-08 8:51 UTC|newest] Thread overview: 68+ messages / expand[flat|nested] mbox.gz Atom feed top 2012-08-07 12:31 [RFC PATCH 0/6] Improve hugepage allocation success rates under load Mel Gorman 2012-08-07 12:31 ` Mel Gorman 2012-08-07 12:31 ` [PATCH 1/6] mm: compaction: Update comment in try_to_compact_pages Mel Gorman 2012-08-07 12:31 ` Mel Gorman 2012-08-07 13:19 ` Rik van Riel 2012-08-07 13:19 ` Rik van Riel 2012-08-07 23:25 ` Minchan Kim 2012-08-07 23:25 ` Minchan Kim 2012-08-07 12:31 ` [PATCH 2/6] mm: vmscan: Scale number of pages reclaimed by reclaim/compaction based on failures Mel Gorman 2012-08-07 12:31 ` Mel Gorman 2012-08-07 13:23 ` Rik van Riel 2012-08-07 13:23 ` Rik van Riel 2012-08-08 1:48 ` Minchan Kim 2012-08-08 1:48 ` Minchan Kim 2012-08-08 7:55 ` Mel Gorman 2012-08-08 7:55 ` Mel Gorman 2012-08-08 8:27 ` Minchan Kim 2012-08-08 8:27 ` Minchan Kim 2012-08-08 8:51 ` Mel Gorman [this message] 2012-08-08 8:51 ` Mel Gorman 2012-08-08 23:51 ` Minchan Kim 2012-08-08 23:51 ` Minchan Kim 2012-08-09 7:49 ` Mel Gorman 2012-08-09 7:49 ` Mel Gorman 2012-08-09 8:27 ` Minchan Kim 2012-08-09 8:27 ` Minchan Kim 2012-08-09 9:20 ` Mel Gorman 2012-08-09 9:20 ` Mel Gorman 2012-08-09 20:29 ` Rik van Riel 2012-08-09 20:29 ` Rik van Riel 2012-08-10 8:14 ` Mel Gorman 2012-08-10 8:14 ` Mel Gorman 2012-08-09 23:27 ` Minchan Kim 2012-08-09 23:27 ` Minchan Kim 2012-08-10 8:34 ` Mel Gorman 2012-08-10 8:34 ` Mel Gorman 2012-08-10 8:48 ` Minchan Kim 2012-08-10 8:48 ` Minchan Kim 2012-08-07 12:31 ` [PATCH 3/6] mm: kswapd: Continue reclaiming for reclaim/compaction if the minimum number of pages have not been reclaimed Mel Gorman 2012-08-07 12:31 ` Mel Gorman 2012-08-07 13:26 ` Rik van Riel 2012-08-07 13:26 ` Rik van Riel 2012-08-08 2:07 ` Minchan Kim 2012-08-08 2:07 ` Minchan Kim 2012-08-08 9:07 ` Mel Gorman 2012-08-08 9:07 ` Mel Gorman 2012-08-08 9:58 ` Mel Gorman 2012-08-08 9:58 ` Mel Gorman 2012-08-07 12:31 ` [PATCH 4/6] mm: compaction: Capture a suitable high-order page immediately when it is made available Mel Gorman 2012-08-07 12:31 ` Mel Gorman 2012-08-07 13:30 ` Rik van Riel 2012-08-07 13:30 ` Rik van Riel 2012-08-07 12:31 ` [PATCH 5/6] mm: have order > 0 compaction start off where it left Mel Gorman 2012-08-07 12:31 ` Mel Gorman 2012-08-07 12:31 ` [PATCH 6/6] mm: have order > 0 compaction start near a pageblock with free pages Mel Gorman 2012-08-07 12:31 ` Mel Gorman 2012-08-07 14:45 ` Rik van Riel 2012-08-07 14:45 ` Rik van Riel 2012-08-07 14:52 ` Mel Gorman 2012-08-07 14:52 ` Mel Gorman 2012-08-07 15:20 ` Jim Schutt 2012-08-07 15:20 ` Jim Schutt 2012-08-07 15:45 ` Mel Gorman 2012-08-07 15:45 ` Mel Gorman 2012-08-08 4:36 ` Minchan Kim 2012-08-08 4:36 ` Minchan Kim 2012-08-08 10:18 ` Mel Gorman 2012-08-08 10:18 ` 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=20120808085112.GJ29814@suse.de \ --to=mgorman@suse.de \ --cc=jaschut@sandia.gov \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-mm@kvack.org \ --cc=minchan@kernel.org \ --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.