From: Vlastimil Babka <vbabka@suse.cz> To: Johannes Weiner <hannes@cmpxchg.org> Cc: linux-mm@kvack.org, Joonsoo Kim <iamjoonsoo.kim@lge.com>, David Rientjes <rientjes@google.com>, Mel Gorman <mgorman@techsingularity.net>, linux-kernel@vger.kernel.org, kernel-team@fb.com Subject: Re: [PATCH v2 07/10] mm, compaction: restrict async compaction to pageblocks of same migratetype Date: Fri, 17 Feb 2017 17:32:00 +0100 [thread overview] Message-ID: <a0409d22-6794-bb33-6bdd-438b386412a3@suse.cz> (raw) In-Reply-To: <20170214201000.GH2450@cmpxchg.org> On 02/14/2017 09:10 PM, Johannes Weiner wrote: > On Fri, Feb 10, 2017 at 06:23:40PM +0100, Vlastimil Babka wrote: >> The migrate scanner in async compaction is currently limited to MIGRATE_MOVABLE >> pageblocks. This is a heuristic intended to reduce latency, based on the >> assumption that non-MOVABLE pageblocks are unlikely to contain movable pages. >> >> However, with the exception of THP's, most high-order allocations are not >> movable. Should the async compaction succeed, this increases the chance that >> the non-MOVABLE allocations will fallback to a MOVABLE pageblock, making the >> long-term fragmentation worse. >> >> This patch attempts to help the situation by changing async direct compaction >> so that the migrate scanner only scans the pageblocks of the requested >> migratetype. If it's a non-MOVABLE type and there are such pageblocks that do >> contain movable pages, chances are that the allocation can succeed within one >> of such pageblocks, removing the need for a fallback. If that fails, the >> subsequent sync attempt will ignore this restriction. >> >> Signed-off-by: Vlastimil Babka <vbabka@suse.cz> > > Yes, IMO we should make the async compaction scanner decontaminate > unmovable blocks. This is because we fall back to other-typed blocks > before we reclaim, Which we could change too, patch 9 is a step in that direction. > so any unmovable blocks that aren't perfectly > occupied will fill with greedy page cache (and order-0 doesn't steal > blocks back to make them compactable again). order-0 allocation can actually steal the block back, the decisions to steal are based on the order of the free pages in the fallback block, not on the allocation order. But maybe I'm not sure what exactly you meant here. > Subsequent unmovable > higher-order allocations in turn are more likely to fall back and > steal more movable blocks. Yes. > As long as we have vastly more movable blocks than unmovable blocks, > continuous page cache turnover will counteract this negative trend - > pages are reclaimed mostly from movable blocks and some unmovable > blocks, while new cache allocations are placed into the freed movable > blocks - slowly moving cache out from unmovable blocks into movable > ones. But that effect is independent of the rate of higher-order > allocations and can be overwhelmed, so I think it makes sense to > involve compaction directly in decontamination. Interesting observation, I agree. > The thing I'm not entirely certain about is the aggressiveness of this > patch. Instead of restricting the async scanner to blocks of the same > migratetype, wouldn't it be better (in terms of allocation latency) to > simply let it compact *all* block types? Yes it would help allocation latency, but I'm afraid it will remove most of the decontamination effect. > Maybe changing it to look at > unmovable blocks is enough to curb cross-contamination. Sure there > will still be some, but now we're matching the decontamination rate to > the rate of !movable higher-order allocations and don't just rely on > the independent cache turnover rate, which during higher-order bursts > might not be high enough to prevent an expansion of unmovable blocks. The rate of compaction attempts is matched with allocations, but the probability of compaction scanner being in unmovable block is low when the majority of blocks are movable. So the decontamination rate is proportional but much smaller. > Does that make sense? I guess I can try and look at the stats, but I have doubts. Thanks for the feedback!
WARNING: multiple messages have this Message-ID (diff)
From: Vlastimil Babka <vbabka@suse.cz> To: Johannes Weiner <hannes@cmpxchg.org> Cc: linux-mm@kvack.org, Joonsoo Kim <iamjoonsoo.kim@lge.com>, David Rientjes <rientjes@google.com>, Mel Gorman <mgorman@techsingularity.net>, linux-kernel@vger.kernel.org, kernel-team@fb.com Subject: Re: [PATCH v2 07/10] mm, compaction: restrict async compaction to pageblocks of same migratetype Date: Fri, 17 Feb 2017 17:32:00 +0100 [thread overview] Message-ID: <a0409d22-6794-bb33-6bdd-438b386412a3@suse.cz> (raw) In-Reply-To: <20170214201000.GH2450@cmpxchg.org> On 02/14/2017 09:10 PM, Johannes Weiner wrote: > On Fri, Feb 10, 2017 at 06:23:40PM +0100, Vlastimil Babka wrote: >> The migrate scanner in async compaction is currently limited to MIGRATE_MOVABLE >> pageblocks. This is a heuristic intended to reduce latency, based on the >> assumption that non-MOVABLE pageblocks are unlikely to contain movable pages. >> >> However, with the exception of THP's, most high-order allocations are not >> movable. Should the async compaction succeed, this increases the chance that >> the non-MOVABLE allocations will fallback to a MOVABLE pageblock, making the >> long-term fragmentation worse. >> >> This patch attempts to help the situation by changing async direct compaction >> so that the migrate scanner only scans the pageblocks of the requested >> migratetype. If it's a non-MOVABLE type and there are such pageblocks that do >> contain movable pages, chances are that the allocation can succeed within one >> of such pageblocks, removing the need for a fallback. If that fails, the >> subsequent sync attempt will ignore this restriction. >> >> Signed-off-by: Vlastimil Babka <vbabka@suse.cz> > > Yes, IMO we should make the async compaction scanner decontaminate > unmovable blocks. This is because we fall back to other-typed blocks > before we reclaim, Which we could change too, patch 9 is a step in that direction. > so any unmovable blocks that aren't perfectly > occupied will fill with greedy page cache (and order-0 doesn't steal > blocks back to make them compactable again). order-0 allocation can actually steal the block back, the decisions to steal are based on the order of the free pages in the fallback block, not on the allocation order. But maybe I'm not sure what exactly you meant here. > Subsequent unmovable > higher-order allocations in turn are more likely to fall back and > steal more movable blocks. Yes. > As long as we have vastly more movable blocks than unmovable blocks, > continuous page cache turnover will counteract this negative trend - > pages are reclaimed mostly from movable blocks and some unmovable > blocks, while new cache allocations are placed into the freed movable > blocks - slowly moving cache out from unmovable blocks into movable > ones. But that effect is independent of the rate of higher-order > allocations and can be overwhelmed, so I think it makes sense to > involve compaction directly in decontamination. Interesting observation, I agree. > The thing I'm not entirely certain about is the aggressiveness of this > patch. Instead of restricting the async scanner to blocks of the same > migratetype, wouldn't it be better (in terms of allocation latency) to > simply let it compact *all* block types? Yes it would help allocation latency, but I'm afraid it will remove most of the decontamination effect. > Maybe changing it to look at > unmovable blocks is enough to curb cross-contamination. Sure there > will still be some, but now we're matching the decontamination rate to > the rate of !movable higher-order allocations and don't just rely on > the independent cache turnover rate, which during higher-order bursts > might not be high enough to prevent an expansion of unmovable blocks. The rate of compaction attempts is matched with allocations, but the probability of compaction scanner being in unmovable block is low when the majority of blocks are movable. So the decontamination rate is proportional but much smaller. > Does that make sense? I guess I can try and look at the stats, but I have doubts. Thanks for the feedback! -- 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:[~2017-02-17 16:32 UTC|newest] Thread overview: 92+ messages / expand[flat|nested] mbox.gz Atom feed top 2017-02-10 17:23 [PATCH v2 00/10] try to reduce fragmenting fallbacks Vlastimil Babka 2017-02-10 17:23 ` Vlastimil Babka 2017-02-10 17:23 ` [PATCH v2 01/10] mm, compaction: reorder fields in struct compact_control Vlastimil Babka 2017-02-10 17:23 ` Vlastimil Babka 2017-02-13 10:49 ` Mel Gorman 2017-02-13 10:49 ` Mel Gorman 2017-02-14 16:33 ` Johannes Weiner 2017-02-14 16:33 ` Johannes Weiner 2017-02-10 17:23 ` [PATCH v2 02/10] mm, compaction: remove redundant watermark check in compact_finished() Vlastimil Babka 2017-02-10 17:23 ` Vlastimil Babka 2017-02-13 10:49 ` Mel Gorman 2017-02-13 10:49 ` Mel Gorman 2017-02-14 16:34 ` Johannes Weiner 2017-02-14 16:34 ` Johannes Weiner 2017-02-10 17:23 ` [PATCH v2 03/10] mm, page_alloc: split smallest stolen page in fallback Vlastimil Babka 2017-02-10 17:23 ` Vlastimil Babka 2017-02-13 10:51 ` Mel Gorman 2017-02-13 10:51 ` Mel Gorman 2017-02-13 10:54 ` Vlastimil Babka 2017-02-13 10:54 ` Vlastimil Babka 2017-02-14 16:59 ` Johannes Weiner 2017-02-14 16:59 ` Johannes Weiner 2017-02-10 17:23 ` [PATCH v2 04/10] mm, page_alloc: count movable pages when stealing from pageblock Vlastimil Babka 2017-02-10 17:23 ` Vlastimil Babka 2017-02-13 10:53 ` Mel Gorman 2017-02-13 10:53 ` Mel Gorman 2017-02-14 10:07 ` Xishi Qiu 2017-02-14 10:07 ` Xishi Qiu 2017-02-15 10:47 ` Vlastimil Babka 2017-02-15 10:47 ` Vlastimil Babka 2017-02-15 11:56 ` Xishi Qiu 2017-02-15 11:56 ` Xishi Qiu 2017-02-17 16:21 ` Vlastimil Babka 2017-02-17 16:21 ` Vlastimil Babka 2017-02-14 18:10 ` Johannes Weiner 2017-02-14 18:10 ` Johannes Weiner 2017-02-17 16:09 ` Vlastimil Babka 2017-02-17 16:09 ` Vlastimil Babka 2017-02-10 17:23 ` [PATCH v2 05/10] mm, compaction: change migrate_async_suitable() to suitable_migration_source() Vlastimil Babka 2017-02-10 17:23 ` Vlastimil Babka 2017-02-13 10:53 ` Mel Gorman 2017-02-13 10:53 ` Mel Gorman 2017-02-14 18:12 ` Johannes Weiner 2017-02-14 18:12 ` Johannes Weiner 2017-02-10 17:23 ` [PATCH v2 06/10] mm, compaction: add migratetype to compact_control Vlastimil Babka 2017-02-10 17:23 ` Vlastimil Babka 2017-02-13 10:53 ` Mel Gorman 2017-02-13 10:53 ` Mel Gorman 2017-02-14 18:15 ` Johannes Weiner 2017-02-14 18:15 ` Johannes Weiner 2017-02-10 17:23 ` [PATCH v2 07/10] mm, compaction: restrict async compaction to pageblocks of same migratetype Vlastimil Babka 2017-02-10 17:23 ` Vlastimil Babka 2017-02-13 10:56 ` Mel Gorman 2017-02-13 10:56 ` Mel Gorman 2017-02-14 20:10 ` Johannes Weiner 2017-02-14 20:10 ` Johannes Weiner 2017-02-17 16:32 ` Vlastimil Babka [this message] 2017-02-17 16:32 ` Vlastimil Babka 2017-02-17 17:39 ` Johannes Weiner 2017-02-17 17:39 ` Johannes Weiner 2017-02-10 17:23 ` [PATCH v2 08/10] mm, compaction: finish whole pageblock to reduce fragmentation Vlastimil Babka 2017-02-10 17:23 ` Vlastimil Babka 2017-02-13 10:57 ` Mel Gorman 2017-02-13 10:57 ` Mel Gorman 2017-02-16 11:44 ` Johannes Weiner 2017-02-16 11:44 ` Johannes Weiner 2017-02-10 17:23 ` [RFC v2 09/10] mm, page_alloc: disallow migratetype fallback in fastpath Vlastimil Babka 2017-02-10 17:23 ` Vlastimil Babka 2017-02-10 17:23 ` [RFC v2 10/10] mm, page_alloc: introduce MIGRATE_MIXED migratetype Vlastimil Babka 2017-02-10 17:23 ` Vlastimil Babka 2017-03-08 2:16 ` Yisheng Xie 2017-03-08 2:16 ` Yisheng Xie 2017-03-08 7:07 ` Vlastimil Babka 2017-03-08 7:07 ` Vlastimil Babka 2017-03-13 2:16 ` Yisheng Xie 2017-03-13 2:16 ` Yisheng Xie 2017-02-13 11:07 ` [PATCH v2 00/10] try to reduce fragmenting fallbacks Mel Gorman 2017-02-13 11:07 ` Mel Gorman 2017-02-15 14:29 ` Vlastimil Babka 2017-02-15 14:29 ` Vlastimil Babka 2017-02-15 16:11 ` Vlastimil Babka 2017-02-15 16:11 ` Vlastimil Babka 2017-02-15 20:11 ` Vlastimil Babka 2017-02-15 20:11 ` Vlastimil Babka 2017-02-16 15:12 ` Vlastimil Babka 2017-02-16 15:12 ` Vlastimil Babka 2017-02-17 15:24 ` Vlastimil Babka 2017-02-17 15:24 ` Vlastimil Babka 2017-02-20 12:30 ` Vlastimil Babka 2017-02-20 12:30 ` Vlastimil Babka 2017-02-23 16:01 ` Mel Gorman 2017-02-23 16:01 ` 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=a0409d22-6794-bb33-6bdd-438b386412a3@suse.cz \ --to=vbabka@suse.cz \ --cc=hannes@cmpxchg.org \ --cc=iamjoonsoo.kim@lge.com \ --cc=kernel-team@fb.com \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-mm@kvack.org \ --cc=mgorman@techsingularity.net \ --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.