Re: [PATCH 2/5] mm: page_alloc: optimize pfn_range_valid_contig()

[Oscar Salvador <osalvador@suse.de>]

On Mon, Jan 12, 2026 at 11:09:51PM +0800, Kefeng Wang wrote:
> The alloc_contig_pages() spends a significant amount of time within
> pfn_range_valid_contig().
> 
> - set_max_huge_pages
>    - 99.98% alloc_pool_huge_folio
>         only_alloc_fresh_hugetlb_folio.isra.0
>       - alloc_contig_frozen_pages_noprof
>          - 87.00% pfn_range_valid_contig
>               pfn_to_online_page
>          - 12.91% alloc_contig_frozen_range_noprof
>               4.51% replace_free_hugepage_folios
>             - 4.02% prep_new_page
>                  prep_compound_page
>             - 2.98% undo_isolate_page_range
>                - 2.79% unset_migratetype_isolate
>                   - 2.75% __move_freepages_block_isolate
>                        2.71% __move_freepages_block
>             - 0.98% start_isolate_page_range
>                  0.66% set_migratetype_isolate
> 
> To optimize this process, use the new helper has_unmovable_pages()
> to avoid more unnecessary iterations for compound pages, such as
> THP, and high-order buddy pages, which significantly improving the
> efficiency of contiguous memory allocation.
> 
> A simple test on machine with 114G free memory, allocate 120 * 1G
> HugeTLB folios(104 successfully returned),
> 
>   time echo 120 > /sys/kernel/mm/hugepages/hugepages-1048576kB/nr_hugepages
> 
> Before: 0m3.605s
> After:  0m0.602s
> 
> Signed-off-by: Kefeng Wang <wangkefeng.wang@huawei.com>

Looks good to me, just have a question below:

Reviewed-by: Oscar Salvador <osalvador@suse.de>

>  mm/page_alloc.c | 25 ++++++++-----------------
>  1 file changed, 8 insertions(+), 17 deletions(-)
> 
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index d8d5379c44dc..813c5f57883f 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -7183,9 +7185,6 @@ static bool pfn_range_valid_contig(struct zone *z, unsigned long start_pfn,
>  		if (PageHuge(page)) {
>  			unsigned int order;
>  
> -			if (!IS_ENABLED(CONFIG_ARCH_ENABLE_HUGEPAGE_MIGRATION))
> -				return false;
> -
>  			if (skip_hugetlb) {
>  				*skipped_hugetlb = true;
>  				return false;
> @@ -7196,17 +7195,9 @@ static bool pfn_range_valid_contig(struct zone *z, unsigned long start_pfn,
>  			if ((order >= MAX_FOLIO_ORDER) ||

Does this not get already covered in page_is_unmovable() somehow?
size_to_hstate() would return no state for order >= MAX_FOLIO_ORDER
folio sizes?
I mean, it is subtle, and I am perfectly fine leaving as is, just asking.

 

-- 
Oscar Salvador
SUSE Labs