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

[Kefeng Wang <wangkefeng.wang@huawei.com>]

On 2026/1/13 1:02, Zi Yan wrote:
> On 12 Jan 2026, at 10:09, 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()
> 
> s/has_unmovable_pages/page_is_unmovable

Indeed.

> 
>> to avoid more unnecessary iterations for compound pages, such as
>> THP, and high-order buddy pages, which significantly improving the
> 
> s/THP/THP not on LRU/

Sure

> 
>> 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>
>> ---
>>   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
>> @@ -7157,18 +7157,20 @@ static bool pfn_range_valid_contig(struct zone *z, unsigned long start_pfn,
>>   				   unsigned long nr_pages, bool skip_hugetlb,
>>   				   bool *skipped_hugetlb)
>>   {
>> -	unsigned long i, end_pfn = start_pfn + nr_pages;
>> +	unsigned long end_pfn = start_pfn + nr_pages;
>>   	struct page *page;
>>
>> -	for (i = start_pfn; i < end_pfn; i++) {
>> -		page = pfn_to_online_page(i);
>> +	while (start_pfn < end_pfn) {
>> +		unsigned long step = 1;
>> +
>> +		page = pfn_to_online_page(start_pfn);
>>   		if (!page)
>>   			return false;
>>
>>   		if (page_zone(page) != z)
>>   			return false;
>>
>> -		if (PageReserved(page))
>> +		if (page_is_unmovable(z, page, PB_ISOLATE_MODE_OTHER, &step))
>>   			return false;
>>
>>   		/*
>> @@ -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) ||
>>   			    (nr_pages <= (1 << order)))
>>   				return false;
> 
> How does page_is_unmovable() interact with the code inside “if (PageHuge(page))”?
> page_is_unmovable() only identify 1GB hugetlb as unmovable, so skip_hugetlb still
> works?

Initially, I wanted to move the skip_hugetlb processing into a new
page_is_unmovable() by introducing a new PB_ISOLATE_MODE, passing the
skip_hugetlb/skipped_hugetlb/nr_pages to page_is_unmovable(), it looks
very complicated/ugly.

if (PageHuage()) {
	if(page is unmovable)
		return;
	skip_hugetlb processing
}

Back to the current code before I made any changes, skip_hugetlb logical
only works for movable huge pages by checking
CONFIG_ARCH_ENABLE_HUGEPAGE_MIGRATION, the checking is not incomplete
since no runtime check, but the new helper made a better judgment.



And after changes,

if (page_is_unmovale())
	return

if (PageHuge())
	skip_hugetlb processing
	
I don' change the skip hugetlb logical, the only drawback is the
PageHuge is checked twice, Maybe I miss something?

> 
>> -
>> -			/*
>> -			 * Reaching this point means we've encounted a huge page
>> -			 * smaller than nr_pages, skip all pfn's for that page.
>> -			 *
>> -			 * We can't get here from a tail-PageHuge, as it implies
>> -			 * we started a scan in the middle of a hugepage larger
>> -			 * than nr_pages - which the prior check filters for.
>> -			 */
>> -			i += (1 << order) - 1;
>>   		}
>> +
>> +		start_pfn += step;
>>   	}
>>   	return true;
>>   }
>> -- 
>> 2.27.0
> 
> 
> Best Regards,
> Yan, Zi