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

[Andrew Morton <akpm@linux-foundation.org>]

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!

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

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?