Message ID | 20181214230310.572-8-mgorman@techsingularity.net (mailing list archive) |
---|---|
State | New, archived |
Headers | show |
Series | Increase success rates and reduce latency of compaction v1 | expand |
On 12/15/18 12:03 AM, Mel Gorman wrote: > When compaction is finishing, it uses a flag to ensure the pageblock is > complete. However, in general it makes sense to always complete migration > of a pageblock. Minimally, skip information is based on a pageblock and > partially scanned pageblocks may incur more scanning in the future. The > pageblock skip handling also becomes more strict later in the series and > the hint is more useful if a complete pageblock was always scanned. > > The impact here is potentially on latencies as more scanning is done > but it's not a consistent win or loss as the scanning is not always a > high percentage of the pageblock and sometimes it is offset by future > reductions in scanning. Hence, the results are not presented this time as > it's a mix of gains/losses without any clear pattern. However, completing > scanning of the pageblock is important for later patches. > > Signed-off-by: Mel Gorman <mgorman@techsingularity.net> Acked-by: Vlastimil Babka <vbabka@suse.cz>
diff --git a/mm/compaction.c b/mm/compaction.c index 8134dba47584..4f51435c645a 100644 --- a/mm/compaction.c +++ b/mm/compaction.c @@ -1338,16 +1338,14 @@ static enum compact_result __compact_finished(struct compact_control *cc) if (is_via_compact_memory(cc->order)) return COMPACT_CONTINUE; - if (cc->finishing_block) { - /* - * We have finished the pageblock, but better check again that - * we really succeeded. - */ - if (IS_ALIGNED(cc->migrate_pfn, pageblock_nr_pages)) - cc->finishing_block = false; - else - return COMPACT_CONTINUE; - } + /* + * Always finish scanning a pageblock to reduce the possibility of + * fallbacks in the future. This is particularly important when + * migration source is unmovable/reclaimable but it's not worth + * special casing. + */ + if (!IS_ALIGNED(cc->migrate_pfn, pageblock_nr_pages)) + return COMPACT_CONTINUE; /* Direct compactor: Is a suitable page free? */ for (order = cc->order; order < MAX_ORDER; order++) { @@ -1389,7 +1387,6 @@ static enum compact_result __compact_finished(struct compact_control *cc) return COMPACT_SUCCESS; } - cc->finishing_block = true; return COMPACT_CONTINUE; } } diff --git a/mm/internal.h b/mm/internal.h index f40d06d70683..9b32f4cab0ae 100644 --- a/mm/internal.h +++ b/mm/internal.h @@ -203,7 +203,6 @@ struct compact_control { bool direct_compaction; /* False from kcompactd or /proc/... */ bool whole_zone; /* Whole zone should/has been scanned */ bool contended; /* Signal lock or sched contention */ - bool finishing_block; /* Finishing current pageblock */ }; unsigned long
When compaction is finishing, it uses a flag to ensure the pageblock is complete. However, in general it makes sense to always complete migration of a pageblock. Minimally, skip information is based on a pageblock and partially scanned pageblocks may incur more scanning in the future. The pageblock skip handling also becomes more strict later in the series and the hint is more useful if a complete pageblock was always scanned. The impact here is potentially on latencies as more scanning is done but it's not a consistent win or loss as the scanning is not always a high percentage of the pageblock and sometimes it is offset by future reductions in scanning. Hence, the results are not presented this time as it's a mix of gains/losses without any clear pattern. However, completing scanning of the pageblock is important for later patches. Signed-off-by: Mel Gorman <mgorman@techsingularity.net> --- mm/compaction.c | 19 ++++++++----------- mm/internal.h | 1 - 2 files changed, 8 insertions(+), 12 deletions(-)