Re: [PATCH 3/4] mm: compaction: Update pageblock skip when first migration candidate is not at the start

Vlastimil Babka
2023-06-02T12:20:27Z

On 6/2/23 13:16, Mel Gorman wrote:
> On Mon, May 29, 2023 at 02:43:48PM +0200, Vlastimil Babka wrote:
>> On 5/29/23 12:33, Mel Gorman wrote:
>> > 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 :(
>>
>> Yeah that should work! I think it should be even folded to 3/4 but if you
>> want separate, fine too.
>>
>
> I was not happy with the test results so limited the scope of the patch
> which performed much better both in terms of absolute performance and
> compaction activity.

That's surprising. Does that mean that if we isolate COMPACT_CLUSTER_MAX
pages, migrate them without failing, but it's not enough to succeed (i.e.
there are more pages we need to migrate to free up a whole pageblock), it's
better to give up on the rest of the pageblock rather than continue? As
that's AFAIU the scenario where cc->finish_pageblock is false when we
revisit an unfinished pageblock.

Are you still ok with this version?

It's better than previously in that cc->finish_pageblock == true case is not
sabotaged anymore. But the result as described above seems to be a weird
non-intuitive and non-obvious heuristic. How did the test differences look like?

> Thanks
>
> --8<--
> mm: compaction: Update pageblock skip when first migration candidate is not at the start -fix
>
> Vlastimil Babka pointed out the following problem with
> mm-compaction-update-pageblock-skip-when-first-migration-candidate-is-not-at-the-start.patch
>
> 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.
>
> He is correct and a partial rescan as implemented in "mm, compaction:
> finish pageblocks on complete migration failure" would abort
> prematurely.
>
> Test and set the skip bit when acquiring "exclusive access" to a pageblock
> for migration but only abort if the calling context is rescanning to
> finish a pageblock.

Should it say NOT rescanning to finish a pageblock?

> This is a fix for the mmotm patch
> mm-compaction-update-pageblock-skip-when-first-migration-candidate-is-not-at-the-start.patch
>
> Signed-off-by: Mel Gorman <mgorman@techsingularity.net>
> ---
> mm/compaction.c | 10 ++++++++--
> 1 file changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/mm/compaction.c b/mm/compaction.c
> index 91af6a8b7a98..300aa968a0cf 100644
> --- a/mm/compaction.c
> +++ b/mm/compaction.c
> @@ -1069,11 +1069,17 @@ 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. If marked for
> + * skip, the scan is aborted unless the current context
> + * is a rescan to 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) &&
> + !cc->finish_pageblock) {
> goto isolate_abort;
> + }
> }
>
> /*