Re: [PATCH v5 10/17] mm/hugetlb: switch HugeTLB to section-based vmemmap optimization

[Muchun Song <muchun.song@linux.dev>]

> On Sep 9, 2026, at 17:58, David Hildenbrand (Arm) <david@kernel.org> wrote:
> 
> On 8/25/26 10:46, Muchun Song wrote:
>> HugeTLB bootmem vmemmap optimization still carries its own early setup
>> path, including pre-populating optimized mappings before the generic
>> sparse-vmemmap code runs.
>> 
>> Now that the section-based vmemmap optimization can derive HugeTLB
>> vmemmap deduplication from section metadata, HugeTLB only needs to mark
>> the bootmem huge page range with the appropriate order. The generic
>> sparse-vmemmap population path can then allocate and map the shared tail
>> vmemmap pages without any HugeTLB-specific early population code.
>> 
>> Do that by setting the section order when a bootmem huge page is
>> allocated and dropping the dedicated pre-HVO helpers and related
>> special-casing.
>> 
>> This removes duplicate early setup logic and switches HugeTLB to the
>> section-based vmemmap optimization path.
>> 
>> Signed-off-by: Muchun Song <songmuchun@bytedance.com>
>> Acked-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
>> ---
>> v3:
>> - Use the order-based helper for the bootmem vmemmap-optimized check
>> 
>> v2:
>> - Collect Acked-by from Mike Rapoport
>> ---
>> include/linux/hugetlb.h |  1 -
>> include/linux/mm.h      |  3 --
>> mm/hugetlb.c            | 30 ++------------
>> mm/hugetlb_vmemmap.c    | 90 +++--------------------------------------
>> mm/hugetlb_vmemmap.h    | 14 +++----
>> mm/sparse-vmemmap.c     | 31 --------------
>> mm/sparse.h             | 27 +++++++++++++
>> 7 files changed, 42 insertions(+), 154 deletions(-)
> 
> Nice cleanup.
> 
>> 
>> diff --git a/mm/sparse.h b/mm/sparse.h
>> index e4617f9c8876..049272aba84e 100644
>> --- a/mm/sparse.h
>> +++ b/mm/sparse.h
>> @@ -16,6 +16,24 @@ static inline unsigned int section_order(const struct mem_section *section)
>> return section->order;
>> }
>> 
>> +static inline void section_set_order(struct mem_section *section, unsigned int order)
>> +{
>> + 	VM_WARN_ON(section_order(section) && order && section_order(section) != order);
>> + 	section->order = order;
> 
> As raised previously "section order" is entirely unclear. If this is a compound
> page order we should spell that out.

But I also have another question. Should I also rename the helper name,
like section_set_compound_order? or it is enough to just renaming
the field name?

Thanks.

> 
> 
> -- 
> Cheers,
> 
> David