All of lore.kernel.org
 help / color / mirror / Atom feed
From: Baolin Wang <baolin.wang@linux.alibaba.com>
To: Kemeng Shi <shikemeng@huaweicloud.com>,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org,
	akpm@linux-foundation.org, mgorman@techsingularity.net,
	david@redhat.com
Subject: Re: [PATCH 3/9] mm/compaction: correctly return failure with bogus compound_order in strict mode
Date: Tue, 15 Aug 2023 16:28:54 +0800	[thread overview]
Message-ID: <a8edac8d-8e22-89cf-2c8c-217a54608d27@linux.alibaba.com> (raw)
In-Reply-To: <20230805110711.2975149-4-shikemeng@huaweicloud.com>



On 8/5/2023 7:07 PM, Kemeng Shi wrote:
> In strict mode, we should return 0 if there is any hole in pageblock. If
> we successfully isolated pages at beginning at pageblock and then have a
> bogus compound_order outside pageblock in next page. We will abort search
> loop with blockpfn > end_pfn. Although we will limit blockpfn to end_pfn,
> we will treat it as a successful isolation in strict mode as blockpfn is
> not < end_pfn and return partial isolated pages. Then
> isolate_freepages_range may success unexpectly with hole in isolated
> range.

Yes, that can be happened.

> This patch also removes unnecessary limit for blockpfn to go outside
> by buddy page introduced in fixed commit or by stride introduced after
> fixed commit. Caller could use returned blockpfn to check if full
> pageblock is scanned by test if blockpfn >= end and to get next pfn to
> scan inside isolate_freepages_block on demand.

IMO, I don't think removing the pageblock restriction is worth it, since 
it did not fix anything and will make people more confused, at least to me.

That is to say, it will be surprised that the blockpfn can go outside of 
the pageblock after calling isolate_freepages_block() to just scan only 
one pageblock, and I did not see in detail if this can cause other 
potential problems.

> Fixes: 9fcd6d2e052ee ("mm, compaction: skip compound pages by order in free scanner")
> Signed-off-by: Kemeng Shi <shikemeng@huaweicloud.com>
> ---
>   mm/compaction.c | 21 +++++++++++----------
>   1 file changed, 11 insertions(+), 10 deletions(-)
> 
> diff --git a/mm/compaction.c b/mm/compaction.c
> index fa1b100b0d10..684f6e6cd8bc 100644
> --- a/mm/compaction.c
> +++ b/mm/compaction.c
> @@ -631,6 +631,14 @@ static unsigned long isolate_freepages_block(struct compact_control *cc,
>   				page += (1UL << order) - 1;
>   				nr_scanned += (1UL << order) - 1;
>   			}
> +			/*
> +			 * There is a tiny chance that we have read bogus
> +			 * compound_order(), so be careful to not go outside
> +			 * of the pageblock.
> +			 */
> +			if (unlikely(blockpfn >= end_pfn))
> +				blockpfn = end_pfn - 1;

So we can just add this validation to ensure that the 
isolate_freepages_block() can return 0 if failure is happened, which can 
fix your problem.

> +
>   			goto isolate_fail;
>   		}
>   
> @@ -677,17 +685,10 @@ static unsigned long isolate_freepages_block(struct compact_control *cc,
>   	if (locked)
>   		spin_unlock_irqrestore(&cc->zone->lock, flags);
>   
> -	/*
> -	 * There is a tiny chance that we have read bogus compound_order(),
> -	 * so be careful to not go outside of the pageblock.
> -	 */
> -	if (unlikely(blockpfn > end_pfn))
> -		blockpfn = end_pfn;
> -
>   	trace_mm_compaction_isolate_freepages(*start_pfn, blockpfn,
>   					nr_scanned, total_isolated);
>   
> -	/* Record how far we have got within the block */
> +	/* Record how far we have got */
>   	*start_pfn = blockpfn;
>   
>   	/*
> @@ -1443,7 +1444,7 @@ fast_isolate_around(struct compact_control *cc, unsigned long pfn)
>   	isolate_freepages_block(cc, &start_pfn, end_pfn, &cc->freepages, 1, false);
>   
>   	/* Skip this pageblock in the future as it's full or nearly full */
> -	if (start_pfn == end_pfn && !cc->no_set_skip_hint)
> +	if (start_pfn >= end_pfn && !cc->no_set_skip_hint)
>   		set_pageblock_skip(page);
>   }
>   
> @@ -1712,7 +1713,7 @@ static void isolate_freepages(struct compact_control *cc)
>   					block_end_pfn, freelist, stride, false);
>   
>   		/* Update the skip hint if the full pageblock was scanned */
> -		if (isolate_start_pfn == block_end_pfn)
> +		if (isolate_start_pfn >= block_end_pfn)
>   			update_pageblock_skip(cc, page, block_start_pfn -
>   					      pageblock_nr_pages);
>   

  reply	other threads:[~2023-08-15  8:29 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-08-05 11:07 [PATCH 0/9] Fixes and cleanups to compaction Kemeng Shi
2023-08-05  3:14 ` Matthew Wilcox
2023-08-05  4:07   ` Kemeng Shi
2023-08-05 11:07 ` [PATCH 1/9] mm/compaction: use correct list in move_freelist_{head}/{tail} Kemeng Shi
2023-08-05 17:11   ` Andrew Morton
2023-08-07  0:37     ` Kemeng Shi
2023-08-15  7:16   ` Baolin Wang
2023-08-05 11:07 ` [PATCH 2/9] mm/compaction: call list_is_{first}/{last} more intuitively " Kemeng Shi
2023-08-15  7:49   ` Baolin Wang
2023-08-05 11:07 ` [PATCH 3/9] mm/compaction: correctly return failure with bogus compound_order in strict mode Kemeng Shi
2023-08-15  8:28   ` Baolin Wang [this message]
2023-08-15  9:22     ` Kemeng Shi
2023-08-05 11:07 ` [PATCH 4/9] mm/compaction: simplify pfn iteration in isolate_freepages_range Kemeng Shi
2023-08-15  8:38   ` Baolin Wang
2023-08-15  9:32     ` Kemeng Shi
2023-08-15 10:07       ` Baolin Wang
2023-08-15 10:37         ` Kemeng Shi
2023-08-19 11:58           ` Baolin Wang
2023-08-22  1:37             ` Kemeng Shi
2023-08-24  2:19               ` Baolin Wang
2023-08-05 11:07 ` [PATCH 5/9] mm/compaction: remove repeat compact_blockskip_flush check in reset_isolation_suitable Kemeng Shi
2023-08-15  8:42   ` Baolin Wang
2023-08-05 11:07 ` [PATCH 6/9] mm/compaction: rename is_via_compact_memory to compaction_with_allocation_order Kemeng Shi
2023-08-15  8:58   ` Baolin Wang
2023-08-15 12:04     ` Kemeng Shi
2023-08-19 12:14       ` Baolin Wang
2023-08-22  1:51         ` Kemeng Shi
2023-08-24  2:20           ` Baolin Wang
2023-08-05 11:07 ` [PATCH 7/9] mm/compaction: factor out code to test if we should run compaction for target order Kemeng Shi
2023-08-15  8:53   ` Baolin Wang
2023-08-15 12:10     ` Kemeng Shi
2023-08-19 12:27       ` Baolin Wang
2023-08-22  1:57         ` Kemeng Shi
2023-08-24  2:25           ` Baolin Wang
2023-08-24  2:59             ` Kemeng Shi
2023-08-05 11:07 ` [PATCH 8/9] mm/compaction: call compaction_suit_allocation_order in kcompactd_node_suitable Kemeng Shi
2023-08-05 11:07 ` [PATCH 9/9] mm/compaction: call compaction_suit_allocation_order in kcompactd_do_work Kemeng Shi

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=a8edac8d-8e22-89cf-2c8c-217a54608d27@linux.alibaba.com \
    --to=baolin.wang@linux.alibaba.com \
    --cc=akpm@linux-foundation.org \
    --cc=david@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mgorman@techsingularity.net \
    --cc=shikemeng@huaweicloud.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 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.