Re: [PATCH 1/3] mm: page_alloc: optimize pfn_range_valid_contig()

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

On 2026/1/11 7:43, Andrew Morton wrote:
> On Sat, 10 Jan 2026 12:21:09 +0800 Kefeng Wang <wangkefeng.wang@huawei.com> wrote:
> 
>> The alloc_contig_pages() function spends a significant amount of time
>> within the pfn_range_valid_contig() function.
> 
> Trivia time: saying "the foo() function" is no more useful than simply
> saying "foo()".  "foo() spends a significant..." is shorter and causes
> no information loss!

Sure.

> 
>> - 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, implement a new helper page_is_unmovable(),
>> which reuses the logic from has_unmovable_pages(). This function avoids
>> unnecessary iterations for compound pages, such as THP, and non-compound
>> 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
> 
> Well dang,  I'm surprised that the previous code was so bad.

I found this when testing the previous patch(frozen gigantic folio
allocation), The efficiency of traversing each pfn is too low.

> 
> The patch does a lot of code movement, which makes it hard to see
> what it actually does.  Is it possible to split these apart?
> move-stuff-around, then speed-stuff-up?

OK, will split it.

>