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

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

On 2026/1/13 13:14, Oscar Salvador wrote:
> 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?

Yes, I think so.

> I mean, it is subtle, and I am perfectly fine leaving as is, just asking.
> 
>   
Let's keep it as is for explicit checking.