From: Mel Gorman <mgorman@techsingularity.net> To: David Rientjes <rientjes@google.com> Cc: Vlastimil Babka <vbabka@suse.cz>, Andrea Arcangeli <aarcange@redhat.com>, Linus Torvalds <torvalds@linux-foundation.org>, Michal Hocko <mhocko@kernel.org>, ying.huang@intel.com, s.priebe@profihost.ag, Linux List Kernel Mailing <linux-kernel@vger.kernel.org>, alex.williamson@redhat.com, lkp@01.org, kirill@shutemov.name, Andrew Morton <akpm@linux-foundation.org>, zi.yan@cs.rutgers.edu Subject: Re: [LKP] [mm] ac5b2c1891: vm-scalability.throughput -61.3% regression Date: Fri, 14 Dec 2018 23:11:47 +0000 [thread overview] Message-ID: <20181214231147.GF29005@techsingularity.net> (raw) In-Reply-To: <alpine.DEB.2.21.1812141244450.186427@chino.kir.corp.google.com> On Fri, Dec 14, 2018 at 01:04:11PM -0800, David Rientjes wrote: > On Wed, 12 Dec 2018, Vlastimil Babka wrote: > > > > Regarding the role of direct reclaim in the allocator, I think we need > > > work on the feedback from compaction to determine whether it's worthwhile. > > > That's difficult because of the point I continue to bring up: > > > isolate_freepages() is not necessarily always able to access this freed > > > memory. > > > > That's one of the *many* reasons why having free base pages doesn't > > guarantee compaction success. We can and will improve on that. But I > > don't think it would be e.g. practical to check the pfns of free pages > > wrt compaction scanner positions and decide based on that. > > Yeah, agreed. Rather than proposing that memory is only reclaimed if its > known that it can be accessible to isolate_freepages(), I'm wondering > about the implementation of the freeing scanner entirely. > > In other words, I think there is a lot of potential stranding that occurs > for both scanners that could otherwise result in completely free > pageblocks. If there a single movable page present near the end of the > zone in an otherwise fully free pageblock, surely we can do better than > the current implementation that would never consider this very easy to > compact memory. > While it's somewhat premature, I posted a series before I had a full set of results because it uses free lists to reduce searches and reduces inference between multiple scanners. Preliminary results indicated it boosted allocation success rates by 20%ish, reduced migration scanning by 99% and free scanning by 27%. > The same problem occurs for the migration scanner where we can iterate > over a ton of free memory that is never considered a suitable migration > target. The implementation that attempts to migrate all memory toward the > end of the zone penalizes the freeing scanner when it is reset: we just > iterate over a ton of used pages. > Yes, partially addressed in series. It can be improved significantly but it hit a boundary condition near the points where compaction scanners meet. I dropped the patch in question as it needs more thought on how to deal with the boundary condition without remigrating the blocks close to it. Besides, at 14 patches, it would probably be best to get that reviewed and finalised before building upon it further so review would be welcome. > Has anybody tried a migration scanner that isn't linearly based, rather > finding the highest-order free page of the same migratetype, iterating the > pages of its pageblock, and using this to determine whether the actual > migration will be worthwhile or not? I could imagine pageblock_skip being > repurposed for this as the heuristic. > Yes, but it has downsides. Redoing the same work on pageblocks, tracking state and tracking the exit conditions are tricky. I think it's best to squeeze the most out of the linear scanning first and the series is the first step in that. > It would be interesting to know if anybody has tried using the per-zone > free_area's to determine migration targets and set a bit if it should be > considered a migration source or a migration target. If all pages for a > pageblock are not on free_areas, they are fully used. > Series has patches which implement something similar to this idea. -- Mel Gorman SUSE Labs
WARNING: multiple messages have this Message-ID (diff)
From: Mel Gorman <mgorman@techsingularity.net> To: lkp@lists.01.org Subject: Re: [mm] ac5b2c1891: vm-scalability.throughput -61.3% regression Date: Fri, 14 Dec 2018 23:11:47 +0000 [thread overview] Message-ID: <20181214231147.GF29005@techsingularity.net> (raw) In-Reply-To: <alpine.DEB.2.21.1812141244450.186427@chino.kir.corp.google.com> [-- Attachment #1: Type: text/plain, Size: 3465 bytes --] On Fri, Dec 14, 2018 at 01:04:11PM -0800, David Rientjes wrote: > On Wed, 12 Dec 2018, Vlastimil Babka wrote: > > > > Regarding the role of direct reclaim in the allocator, I think we need > > > work on the feedback from compaction to determine whether it's worthwhile. > > > That's difficult because of the point I continue to bring up: > > > isolate_freepages() is not necessarily always able to access this freed > > > memory. > > > > That's one of the *many* reasons why having free base pages doesn't > > guarantee compaction success. We can and will improve on that. But I > > don't think it would be e.g. practical to check the pfns of free pages > > wrt compaction scanner positions and decide based on that. > > Yeah, agreed. Rather than proposing that memory is only reclaimed if its > known that it can be accessible to isolate_freepages(), I'm wondering > about the implementation of the freeing scanner entirely. > > In other words, I think there is a lot of potential stranding that occurs > for both scanners that could otherwise result in completely free > pageblocks. If there a single movable page present near the end of the > zone in an otherwise fully free pageblock, surely we can do better than > the current implementation that would never consider this very easy to > compact memory. > While it's somewhat premature, I posted a series before I had a full set of results because it uses free lists to reduce searches and reduces inference between multiple scanners. Preliminary results indicated it boosted allocation success rates by 20%ish, reduced migration scanning by 99% and free scanning by 27%. > The same problem occurs for the migration scanner where we can iterate > over a ton of free memory that is never considered a suitable migration > target. The implementation that attempts to migrate all memory toward the > end of the zone penalizes the freeing scanner when it is reset: we just > iterate over a ton of used pages. > Yes, partially addressed in series. It can be improved significantly but it hit a boundary condition near the points where compaction scanners meet. I dropped the patch in question as it needs more thought on how to deal with the boundary condition without remigrating the blocks close to it. Besides, at 14 patches, it would probably be best to get that reviewed and finalised before building upon it further so review would be welcome. > Has anybody tried a migration scanner that isn't linearly based, rather > finding the highest-order free page of the same migratetype, iterating the > pages of its pageblock, and using this to determine whether the actual > migration will be worthwhile or not? I could imagine pageblock_skip being > repurposed for this as the heuristic. > Yes, but it has downsides. Redoing the same work on pageblocks, tracking state and tracking the exit conditions are tricky. I think it's best to squeeze the most out of the linear scanning first and the series is the first step in that. > It would be interesting to know if anybody has tried using the per-zone > free_area's to determine migration targets and set a bit if it should be > considered a migration source or a migration target. If all pages for a > pageblock are not on free_areas, they are fully used. > Series has patches which implement something similar to this idea. -- Mel Gorman SUSE Labs
next prev parent reply other threads:[~2018-12-14 23:11 UTC|newest] Thread overview: 154+ messages / expand[flat|nested] mbox.gz Atom feed top 2018-11-27 6:25 [LKP] [mm] ac5b2c1891: vm-scalability.throughput -61.3% regression kernel test robot 2018-11-27 6:25 ` kernel test robot 2018-11-27 17:08 ` [LKP] " Linus Torvalds 2018-11-27 17:08 ` Linus Torvalds 2018-11-27 18:17 ` [LKP] " Michal Hocko 2018-11-27 18:17 ` Michal Hocko 2018-11-27 18:21 ` [LKP] " Michal Hocko 2018-11-27 18:21 ` Michal Hocko 2018-11-27 19:05 ` [LKP] " Vlastimil Babka 2018-11-27 19:05 ` Vlastimil Babka 2018-11-27 19:16 ` [LKP] " Vlastimil Babka 2018-11-27 19:16 ` Vlastimil Babka 2018-11-27 20:57 ` [LKP] " Andrea Arcangeli 2018-11-27 20:57 ` Andrea Arcangeli 2018-11-27 22:50 ` [LKP] " Linus Torvalds 2018-11-27 22:50 ` Linus Torvalds 2018-11-28 6:30 ` [LKP] " Michal Hocko 2018-11-28 6:30 ` Michal Hocko 2018-11-28 3:20 ` [LKP] " Huang, Ying 2018-11-28 3:20 ` Huang, Ying 2018-11-28 16:48 ` [LKP] " Linus Torvalds 2018-11-28 16:48 ` Linus Torvalds 2018-11-28 18:39 ` [LKP] " Andrea Arcangeli 2018-11-28 18:39 ` Andrea Arcangeli 2018-11-28 23:10 ` [LKP] " David Rientjes 2018-11-28 23:10 ` David Rientjes 2018-12-03 18:01 ` [LKP] " Linus Torvalds 2018-12-03 18:01 ` Linus Torvalds 2018-12-03 18:14 ` [LKP] " Michal Hocko 2018-12-03 18:14 ` Michal Hocko 2018-12-03 18:19 ` [LKP] " Linus Torvalds 2018-12-03 18:19 ` Linus Torvalds 2018-12-03 18:30 ` [LKP] " Michal Hocko 2018-12-03 18:30 ` Michal Hocko 2018-12-03 18:45 ` [LKP] " Linus Torvalds 2018-12-03 18:45 ` Linus Torvalds 2018-12-03 18:59 ` [LKP] " Michal Hocko 2018-12-03 18:59 ` Michal Hocko 2018-12-03 19:23 ` [LKP] " Andrea Arcangeli 2018-12-03 19:23 ` Andrea Arcangeli 2018-12-03 20:26 ` [LKP] " David Rientjes 2018-12-03 20:26 ` David Rientjes 2018-12-03 19:28 ` [LKP] " Linus Torvalds 2018-12-03 19:28 ` Linus Torvalds 2018-12-03 20:12 ` [LKP] " Andrea Arcangeli 2018-12-03 20:12 ` Andrea Arcangeli 2018-12-03 20:36 ` [LKP] " David Rientjes 2018-12-03 20:36 ` David Rientjes 2018-12-03 22:04 ` [LKP] " Linus Torvalds 2018-12-03 22:04 ` Linus Torvalds 2018-12-03 22:27 ` [LKP] " Linus Torvalds 2018-12-03 22:27 ` Linus Torvalds 2018-12-03 22:57 ` [LKP] " David Rientjes 2018-12-03 22:57 ` David Rientjes 2018-12-04 9:22 ` [LKP] " Vlastimil Babka 2018-12-04 9:22 ` Vlastimil Babka 2018-12-04 10:45 ` [LKP] " Mel Gorman 2018-12-04 10:45 ` Mel Gorman 2018-12-05 0:47 ` [LKP] " David Rientjes 2018-12-05 0:47 ` David Rientjes 2018-12-05 9:08 ` [LKP] " Michal Hocko 2018-12-05 9:08 ` Michal Hocko 2018-12-05 10:43 ` [LKP] " Mel Gorman 2018-12-05 10:43 ` Mel Gorman 2018-12-05 11:43 ` [LKP] " Michal Hocko 2018-12-05 11:43 ` Michal Hocko 2018-12-05 10:06 ` [LKP] " Mel Gorman 2018-12-05 10:06 ` Mel Gorman 2018-12-05 20:40 ` [LKP] " Andrea Arcangeli 2018-12-05 20:40 ` Andrea Arcangeli 2018-12-05 21:59 ` [LKP] " David Rientjes 2018-12-05 21:59 ` David Rientjes 2018-12-06 0:00 ` [LKP] " Andrea Arcangeli 2018-12-06 0:00 ` Andrea Arcangeli 2018-12-05 22:03 ` [LKP] " Linus Torvalds 2018-12-05 22:03 ` Linus Torvalds 2018-12-05 22:12 ` [LKP] " David Rientjes 2018-12-05 22:12 ` David Rientjes 2018-12-05 23:36 ` [LKP] " Andrea Arcangeli 2018-12-05 23:36 ` Andrea Arcangeli 2018-12-05 23:51 ` [LKP] " Linus Torvalds 2018-12-05 23:51 ` Linus Torvalds 2018-12-06 0:58 ` [LKP] " Linus Torvalds 2018-12-06 0:58 ` Linus Torvalds 2018-12-06 9:14 ` MADV_HUGEPAGE vs. NUMA semantic (was: Re: [LKP] [mm] ac5b2c1891: vm-scalability.throughput -61.3% regression) Michal Hocko 2018-12-06 9:14 ` MADV_HUGEPAGE vs. NUMA semantic (was: " Michal Hocko 2018-12-06 23:49 ` MADV_HUGEPAGE vs. NUMA semantic (was: Re: [LKP] " David Rientjes 2018-12-06 23:49 ` MADV_HUGEPAGE vs. NUMA semantic (was: " David Rientjes 2018-12-07 7:34 ` MADV_HUGEPAGE vs. NUMA semantic (was: Re: [LKP] " Michal Hocko 2018-12-07 7:34 ` MADV_HUGEPAGE vs. NUMA semantic (was: " Michal Hocko 2018-12-07 4:31 ` MADV_HUGEPAGE vs. NUMA semantic (was: Re: [LKP] " Linus Torvalds 2018-12-07 4:31 ` MADV_HUGEPAGE vs. NUMA semantic (was: " Linus Torvalds 2018-12-07 7:49 ` MADV_HUGEPAGE vs. NUMA semantic (was: Re: [LKP] " Michal Hocko 2018-12-07 7:49 ` MADV_HUGEPAGE vs. NUMA semantic (was: " Michal Hocko 2018-12-07 9:06 ` MADV_HUGEPAGE vs. NUMA semantic (was: Re: [LKP] " Vlastimil Babka 2018-12-07 9:06 ` MADV_HUGEPAGE vs. NUMA semantic (was: " Vlastimil Babka 2018-12-07 23:15 ` MADV_HUGEPAGE vs. NUMA semantic (was: Re: [LKP] " David Rientjes 2018-12-07 23:15 ` MADV_HUGEPAGE vs. NUMA semantic (was: " David Rientjes 2018-12-06 23:43 ` [LKP] [mm] ac5b2c1891: vm-scalability.throughput -61.3% regression David Rientjes 2018-12-06 23:43 ` David Rientjes 2018-12-07 4:01 ` [LKP] " Linus Torvalds 2018-12-07 4:01 ` Linus Torvalds 2018-12-10 0:29 ` [LKP] " David Rientjes 2018-12-10 0:29 ` David Rientjes 2018-12-10 4:49 ` [LKP] " Andrea Arcangeli 2018-12-10 4:49 ` Andrea Arcangeli 2018-12-12 0:37 ` [LKP] " David Rientjes 2018-12-12 0:37 ` David Rientjes 2018-12-12 9:50 ` [LKP] " Michal Hocko 2018-12-12 9:50 ` Michal Hocko 2018-12-12 17:00 ` [LKP] " Andrea Arcangeli 2018-12-12 17:00 ` Andrea Arcangeli 2018-12-14 11:32 ` [LKP] " Michal Hocko 2018-12-14 11:32 ` Michal Hocko 2018-12-12 10:14 ` [LKP] " Vlastimil Babka 2018-12-12 10:14 ` Vlastimil Babka 2018-12-14 21:04 ` [LKP] " David Rientjes 2018-12-14 21:04 ` David Rientjes 2018-12-14 21:33 ` [LKP] " Vlastimil Babka 2018-12-14 21:33 ` Vlastimil Babka 2018-12-21 22:18 ` [LKP] " David Rientjes 2018-12-21 22:18 ` David Rientjes 2018-12-21 22:18 ` [LKP] " David Rientjes 2018-12-22 12:08 ` Mel Gorman 2018-12-22 12:08 ` Mel Gorman 2018-12-14 23:11 ` Mel Gorman [this message] 2018-12-14 23:11 ` Mel Gorman 2018-12-21 22:15 ` [LKP] " David Rientjes 2018-12-21 22:15 ` David Rientjes 2018-12-12 10:44 ` [LKP] " Andrea Arcangeli 2018-12-12 10:44 ` Andrea Arcangeli 2019-04-15 11:48 ` [LKP] " Michal Hocko 2019-04-15 11:48 ` Michal Hocko 2018-12-06 0:18 ` [LKP] " David Rientjes 2018-12-06 0:18 ` David Rientjes 2018-12-06 0:54 ` [LKP] " Andrea Arcangeli 2018-12-06 0:54 ` Andrea Arcangeli 2018-12-06 9:23 ` [LKP] " Vlastimil Babka 2018-12-06 9:23 ` Vlastimil Babka 2018-12-03 20:39 ` [LKP] " David Rientjes 2018-12-03 20:39 ` David Rientjes 2018-12-03 21:25 ` [LKP] " Michal Hocko 2018-12-03 21:25 ` Michal Hocko 2018-12-03 21:53 ` [LKP] " David Rientjes 2018-12-03 21:53 ` David Rientjes 2018-12-04 8:48 ` [LKP] " Michal Hocko 2018-12-04 8:48 ` Michal Hocko 2018-12-05 0:07 ` [LKP] " David Rientjes 2018-12-05 0:07 ` David Rientjes 2018-12-05 10:18 ` [LKP] " Michal Hocko 2018-12-05 10:18 ` Michal Hocko 2018-12-05 19:16 ` [LKP] " David Rientjes 2018-12-05 19:16 ` David Rientjes 2018-11-27 7:23 [LKP] " kernel test robot
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=20181214231147.GF29005@techsingularity.net \ --to=mgorman@techsingularity.net \ --cc=aarcange@redhat.com \ --cc=akpm@linux-foundation.org \ --cc=alex.williamson@redhat.com \ --cc=kirill@shutemov.name \ --cc=linux-kernel@vger.kernel.org \ --cc=lkp@01.org \ --cc=mhocko@kernel.org \ --cc=rientjes@google.com \ --cc=s.priebe@profihost.ag \ --cc=torvalds@linux-foundation.org \ --cc=vbabka@suse.cz \ --cc=ying.huang@intel.com \ --cc=zi.yan@cs.rutgers.edu \ /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.