On Thu, Jan 17, 2019 at 06:58:30PM +0100, Vlastimil Babka wrote: > On 1/4/19 1:50 PM, Mel Gorman wrote: > > The fast isolation of pages can move the scanner faster than is necessary > > depending on the contents of the free list. This patch will only allow > > the fast isolation to initialise the scanner and advance it slowly. The > > primary means of moving the scanner forward is via the linear scanner > > to reduce the likelihood the migration source/target scanners meet > > prematurely triggering a rescan. > > Maybe I've seen enough code today and need to stop, but AFAICS the description > here doesn't match the actual code changes? What I see are some cleanups, and a > change in free scanner that will set pageblock skip bit after a pageblock has > been scanned, even if there were pages isolated, while previously it would set > the skip bit only if nothing was isolated. > The first three hunks could have been split out but it wouldn't help overall. Maybe a changelog rewrite will help; mm, compaction: Reduce premature advancement of the migration target scanner The fast isolation of free pages allows the cached PFN of the free scanner to advance faster than necessary depending on the contents of the free list. The key is that fast_isolate_freepages() can update zone->compact_cached_free_pfn via isolate_freepages_block(). When the fast search fails, the linear scan can start from a point that has skipped valid migration targets, particularly pageblocks with just low-order free pages. This can cause the migration source/target scanners to meet prematurely causing a reset. This patch starts by avoiding an update of the pageblock skip information and cached PFN from isolate_freepages_block() and puts the responsibility of updating that information in the callers. The fast scanner will update the cached PFN if and only if it finds a block that is higher than the existing cached PFN and sets the skip if the pageblock is full or nearly full. The linear scanner will update skipped information and the cached PFN only when a block is completely scanned. The total impact is that the free scanner advances more slowly as it is primarily driven by the linear scanner instead of the fast search. Does that help? -- Mel Gorman SUSE Labs
