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

[Zi Yan <ziy@nvidia.com>]

On 12 Jan 2026, at 20:24, Kefeng Wang wrote:

> 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?

Sounds good to me. Thanks. I just want to double check with you.

With the changes to the commit message, feel free to add

Reviewed-by: Zi Yan <ziy@nvidia.com>

>
>>
>>> -
>>> -			/*
>>> -			 * 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


Best Regards,
Yan, Zi