All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mel Gorman <mgorman@techsingularity.net>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: David Rientjes <rientjes@google.com>,
	Andrea Arcangeli <aarcange@redhat.com>,
	Vlastimil Babka <vbabka@suse.cz>,
	Linux List Kernel Mailing <linux-kernel@vger.kernel.org>,
	Linux-MM <linux-mm@kvack.org>,
	Mel Gorman <mgorman@techsingularity.net>
Subject: [PATCH 00/22] Increase success rates and reduce latency of compaction v3
Date: Fri, 18 Jan 2019 17:51:14 +0000	[thread overview]
Message-ID: <20190118175136.31341-1-mgorman@techsingularity.net> (raw)

This is a drop-in replacement for the series currently in Andrews tree that
incorporates static checking and compile warning fixes (Dan, YueHaibing)
and extensive review feedback from Vlastimil. Big thanks to Vlastimil as
the review was extremely detailed and a number of issues were caught. Not
all the patches have been acked but I think an update is still worthwhile.

Andrew, please drop the series you have and replace it with the following
on the off-chance we get bug reports that are fixed already. Doing this
with -fix patches would be relatively painful for little gain.

Changelog since v2
o Fix static checker warnings						(dan)
o Fix unused variable warnings						(yue)
o Drop patch about PageReserved as there is some abuse of the flag outside
  of the mm core.							(vbabka)
o Drop patch using the bulk free helper as it may be vulnerable to races
  with compaction and gup						(vbabka)
o Drop patch about remote compaction. It's unnecessary at this time and
  unclear what the semantics should even be				(vbabka)
o Changelog fixes and clarifications					(vbabka)
o Free list management and search
  Confined mostly to "mm, compaction: Use free lists to quickly locate
  a migration source" which is arguably the most heavily modified patch
  in this revision							(vbabka, mel)
o Some minor churn, modifications, flow changes that fallout from
  addressing the review feedback					(mel)
o Minor pageblock skip changes, mostly fixing up which patch makes the
  changes so the patches are incremental				(mel)

This series reduces scan rates and success rates of compaction, primarily
by using the free lists to shorten scans, better controlling of skip
information and whether multiple scanners can target the same block and
capturing pageblocks before being stolen by parallel requests. The series
is based on mmotm from January 9th, 2019 with the previous compaction
series reverted.

I'm mostly using thpscale to measure the impact of the series. The
benchmark creates a large file, maps it, faults it, punches holes in the
mapping so that the virtual address space is fragmented and then tries
to allocate THP. It re-executes for different numbers of threads. From a
fragmentation perspective, the workload is relatively benign but it does
stress compaction.

The overall impact on latencies for a 1-socket machine is

				      baseline		      patches
Amean     fault-both-3      3832.09 (   0.00%)     2748.56 *  28.28%*
Amean     fault-both-5      4933.06 (   0.00%)     4255.52 (  13.73%)
Amean     fault-both-7      7017.75 (   0.00%)     6586.93 (   6.14%)
Amean     fault-both-12    11610.51 (   0.00%)     9162.34 *  21.09%*
Amean     fault-both-18    17055.85 (   0.00%)    11530.06 *  32.40%*
Amean     fault-both-24    19306.27 (   0.00%)    17956.13 (   6.99%)
Amean     fault-both-30    22516.49 (   0.00%)    15686.47 *  30.33%*
Amean     fault-both-32    23442.93 (   0.00%)    16564.83 *  29.34%*

The allocation success rates are much improved

			 	 baseline		 patches
Percentage huge-3        85.99 (   0.00%)       97.96 (  13.92%)
Percentage huge-5        88.27 (   0.00%)       96.87 (   9.74%)
Percentage huge-7        85.87 (   0.00%)       94.53 (  10.09%)
Percentage huge-12       82.38 (   0.00%)       98.44 (  19.49%)
Percentage huge-18       83.29 (   0.00%)       99.14 (  19.04%)
Percentage huge-24       81.41 (   0.00%)       97.35 (  19.57%)
Percentage huge-30       80.98 (   0.00%)       98.05 (  21.08%)
Percentage huge-32       80.53 (   0.00%)       97.06 (  20.53%)

That's a nearly perfect allocation success rate.

The biggest impact is on the scan rates

Compaction migrate scanned    55893379    19341254
Compaction free scanned      474739990    11903963

The number of pages scanned for migration was reduced by 65% and the
free scanner was reduced by 97.5%. So much less work in exchange
for lower latency and better success rates.

The series was also evaluated using a workload that heavily fragments
memory but the benefits there are also significant, albeit not presented.

It was commented that we should be rethinking scanning entirely and to
a large extent I agree. However, to achieve that you need a lot of this
series in place first so it's best to make the linear scanners as best
as possible before ripping them out.

 include/linux/compaction.h |    3 +-
 include/linux/mmzone.h     |    2 +
 include/linux/sched.h      |    4 +
 kernel/sched/core.c        |    3 +
 mm/compaction.c            | 1000 ++++++++++++++++++++++++++++++++++----------
 mm/internal.h              |   23 +-
 mm/migrate.c               |    2 +-
 mm/page_alloc.c            |   76 +++-
 8 files changed, 888 insertions(+), 225 deletions(-)

-- 
2.16.4


             reply	other threads:[~2019-01-18 17:51 UTC|newest]

Thread overview: 45+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-01-18 17:51 Mel Gorman [this message]
2019-01-18 17:51 ` [PATCH 01/22] mm, compaction: Shrink compact_control Mel Gorman
2019-01-18 17:51 ` [PATCH 02/22] mm, compaction: Rearrange compact_control Mel Gorman
2019-01-18 17:51 ` [PATCH 03/22] mm, compaction: Remove last_migrated_pfn from compact_control Mel Gorman
2019-01-18 17:51 ` [PATCH 04/22] mm, compaction: Remove unnecessary zone parameter in some instances Mel Gorman
2019-01-18 17:51 ` [PATCH 05/22] mm, compaction: Rename map_pages to split_map_pages Mel Gorman
2019-01-18 17:51 ` [PATCH 06/22] mm, migrate: Immediately fail migration of a page with no migration handler Mel Gorman
2019-01-18 17:51 ` [PATCH 07/22] mm, compaction: Always finish scanning of a full pageblock Mel Gorman
2019-01-18 17:51 ` [PATCH 08/22] mm, compaction: Ignore the fragmentation avoidance boost for isolation and compaction Mel Gorman
2019-01-18 17:51 ` [PATCH 09/22] mm, compaction: Use free lists to quickly locate a migration source Mel Gorman
2019-01-31 13:55   ` Vlastimil Babka
2019-01-31 14:12     ` Vlastimil Babka
2019-02-01 15:06     ` Mel Gorman
2019-02-04  8:55       ` [PATCH] mm, compaction: Use free lists to quickly locate a migration source -fix Mel Gorman
2019-02-08 17:10   ` [PATCH 09/22] mm, compaction: Use free lists to quickly locate a migration source Vlastimil Babka
2019-01-18 17:51 ` [PATCH 10/22] mm, compaction: Keep migration source private to a single compaction instance Mel Gorman
2019-01-18 17:51 ` [PATCH 11/22] mm, compaction: Use free lists to quickly locate a migration target Mel Gorman
2019-01-31 14:52   ` Vlastimil Babka
2019-02-01 14:51     ` Mel Gorman
2019-02-01 14:58       ` Vlastimil Babka
2019-02-04 12:01         ` [PATCH] mm, compaction: Use free lists to quickly locate a migration source -fix Mel Gorman
2021-01-12  5:19     ` [PATCH] mm, compaction: make sure we isolate a valid freepage when high_pfn is used Rokudo Yan
2021-01-12  9:10       ` Mel Gorman
2021-01-12  9:47         ` [PATCH] mm, compaction: move high_pfn to the for loop scope Rokudo Yan
2021-01-12 10:45           ` Mel Gorman
2021-01-12 10:48           ` Vlastimil Babka
2021-01-12 22:27           ` Andrew Morton
2021-01-18  7:41             ` Rokudo Yan
2021-01-18  9:42               ` Mel Gorman
2019-01-18 17:51 ` [PATCH 12/22] mm, compaction: Avoid rescanning the same pageblock multiple times Mel Gorman
2019-01-18 17:51 ` [PATCH 13/22] mm, compaction: Finish pageblock scanning on contention Mel Gorman
2019-01-18 17:51 ` [PATCH 14/22] mm, compaction: Check early for huge pages encountered by the migration scanner Mel Gorman
2019-01-18 17:51 ` [PATCH 15/22] mm, compaction: Keep cached migration PFNs synced for unusable pageblocks Mel Gorman
2019-01-18 17:51 ` [PATCH 16/22] mm, compaction: Rework compact_should_abort as compact_check_resched Mel Gorman
2019-01-18 17:51 ` [PATCH 17/22] mm, compaction: Do not consider a need to reschedule as contention Mel Gorman
2019-01-18 17:51 ` [PATCH 18/22] mm, compaction: Reduce premature advancement of the migration target scanner Mel Gorman
2019-01-18 17:51 ` [PATCH 19/22] mm, compaction: Round-robin the order while searching the free lists for a target Mel Gorman
2019-01-18 17:51 ` [PATCH 20/22] mm, compaction: Sample pageblocks for free pages Mel Gorman
2019-01-31 15:39   ` Vlastimil Babka
2019-01-18 17:51 ` [PATCH 21/22] mm, compaction: Be selective about what pageblocks to clear skip hints Mel Gorman
2019-01-31 15:45   ` Vlastimil Babka
2019-01-18 17:51 ` [PATCH 22/22] mm, compaction: Capture a page under direct compaction Mel Gorman
2019-01-31 16:11   ` Vlastimil Babka
2019-02-01 14:38     ` [PATCH] mm, compaction: Capture a page under direct compaction -fix Mel Gorman
2019-01-24  8:53 ` [PATCH 00/22] Increase success rates and reduce latency of compaction v3 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=20190118175136.31341-1-mgorman@techsingularity.net \
    --to=mgorman@techsingularity.net \
    --cc=aarcange@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=rientjes@google.com \
    --cc=vbabka@suse.cz \
    --subject='Re: [PATCH 00/22] Increase success rates and reduce latency of compaction v3' \
    /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: link

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.