From: Mel Gorman <mgorman@techsingularity.net>
To: Vlastimil Babka <vbabka@suse.cz>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Jiri Slaby <jirislaby@kernel.org>,
Maxim Levitsky <mlevitsk@redhat.com>,
Michal Hocko <mhocko@kernel.org>,
Pedro Falcato <pedro.falcato@gmail.com>,
Paolo Bonzini <pbonzini@redhat.com>,
Chuyi Zhou <zhouchuyi@bytedance.com>,
Linux-MM <linux-mm@kvack.org>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 3/4] mm: compaction: Update pageblock skip when first migration candidate is not at the start
Date: Mon, 29 May 2023 11:33:42 +0100 [thread overview]
Message-ID: <20230529103342.esek6r5fvmft2nky@techsingularity.net> (raw)
In-Reply-To: <e87a9797-c8ce-1959-884a-7f791adeaafc@suse.cz>
On Thu, May 25, 2023 at 03:37:43PM +0200, Vlastimil Babka wrote:
> On 5/15/23 13:33, Mel Gorman wrote:
> > isolate_migratepages_block should mark a pageblock as skip if scanning
> > started on an aligned pageblock boundary but it only updates the skip
> > flag if the first migration candidate is also aligned. Tracing during
> > a compaction stress load (mmtests: workload-usemem-stress-numa-compact)
> > that many pageblocks are not marked skip causing excessive scanning of
> > blocks that had been recently checked. Update pageblock skip based on
> > "valid_page" which is set if scanning started on a pageblock boundary.
> >
> > Signed-off-by: Mel Gorman <mgorman@techsingularity.net>
>
> I wonder if this has an unintended side-effect that if we resume
> isolate_migratepages_block() of a partially compacted pageblock to finish
> it, test_and_set_skip() will now tell us to abort, because we already set
> the skip bit in the previous call. This would include the
> cc->finish_pageblock rescan cases.
>
> So unless I miss something that already prevents that, I agree we should not
> tie setting the skip bit to pageblock_aligned(pfn), but maybe if we are not
> pageblock aligned, we should ignore the already-set skip bit, as it was most
> likely being set by us in the previous iteration and should not prevent us
> from finishing the pageblock?
>
Hmm, I think you're right. While it should not hit the original bug,
migration candidates are missed until the next compaction scan which
could be tricky to detect. Something like this as a separate patch?
Build tested only but the intent is for an unaligned start to set the skip
bet if already unset but otherwise complete the scan. Like earlier fixes,
this might overscan some pageblocks in a given context but we are probably
hitting the limits on how compaction can run efficiently in the current
scheme without causing other side-effects :(
diff --git a/mm/compaction.c b/mm/compaction.c
index 91af6a8b7a98..761a2dd7d78a 100644
--- a/mm/compaction.c
+++ b/mm/compaction.c
@@ -792,6 +792,7 @@ isolate_migratepages_block(struct compact_control *cc, unsigned long low_pfn,
bool skip_on_failure = false;
unsigned long next_skip_pfn = 0;
bool skip_updated = false;
+ bool start_aligned;
int ret = 0;
cc->migrate_pfn = low_pfn;
@@ -824,6 +825,7 @@ isolate_migratepages_block(struct compact_control *cc, unsigned long low_pfn,
}
/* Time to isolate some pages for migration */
+ start_aligned = pageblock_aligned(start_pfn);
for (; low_pfn < end_pfn; low_pfn++) {
if (skip_on_failure && low_pfn >= next_skip_pfn) {
@@ -1069,10 +1071,15 @@ isolate_migratepages_block(struct compact_control *cc, unsigned long low_pfn,
lruvec_memcg_debug(lruvec, page_folio(page));
- /* Try get exclusive access under lock */
+ /* Try get exclusive access under lock. Isolation is
+ * only aborted if the start was pageblock aligned
+ * as this may be a partial resumed scan that set
+ * the bit on a recent scan but the scan must reach
+ * the end of the pageblock.
+ */
if (!skip_updated && valid_page) {
skip_updated = true;
- if (test_and_set_skip(cc, valid_page))
+ if (test_and_set_skip(cc, valid_page) && start_aligned)
goto isolate_abort;
}
next prev parent reply other threads:[~2023-05-29 10:33 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-15 11:33 [PATCH 0/4] Follow-up "Fix excessive CPU usage during compaction" Mel Gorman
2023-05-15 11:33 ` [PATCH 1/4] mm: compaction: Ensure rescanning only happens on partially scanned pageblocks Mel Gorman
2023-05-25 9:57 ` Vlastimil Babka
2023-05-15 11:33 ` [PATCH 2/4] mm: compaction: Only force pageblock scan completion when skip hints are obeyed Mel Gorman
2023-05-25 10:01 ` Vlastimil Babka
2023-05-15 11:33 ` [PATCH 3/4] mm: compaction: Update pageblock skip when first migration candidate is not at the start Mel Gorman
2023-05-25 13:37 ` Vlastimil Babka
2023-05-29 10:33 ` Mel Gorman [this message]
2023-05-29 12:43 ` Vlastimil Babka
2023-06-02 11:16 ` Mel Gorman
2023-06-02 12:19 ` Vlastimil Babka
2023-06-02 12:48 ` Mel Gorman
2023-06-06 13:11 ` Vlastimil Babka
2023-06-07 3:38 ` Baolin Wang
2023-06-07 12:24 ` Mel Gorman
2023-05-15 11:33 ` [PATCH 4/4] Revert "Revert "mm/compaction: fix set skip in fast_find_migrateblock"" Mel Gorman
2023-05-25 13:42 ` Vlastimil Babka
2023-05-19 6:43 ` [PATCH 0/4] Follow-up "Fix excessive CPU usage during compaction" Raghavendra K T
2023-05-21 19:20 ` Mel Gorman
2023-05-23 13:47 ` Baolin Wang
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=20230529103342.esek6r5fvmft2nky@techsingularity.net \
--to=mgorman@techsingularity.net \
--cc=akpm@linux-foundation.org \
--cc=jirislaby@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@kernel.org \
--cc=mlevitsk@redhat.com \
--cc=pbonzini@redhat.com \
--cc=pedro.falcato@gmail.com \
--cc=vbabka@suse.cz \
--cc=zhouchuyi@bytedance.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: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox