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

["David Hildenbrand (Arm)" <david@kernel.org>]

On 9/9/26 15:08, Muchun Song wrote:
> 
> 
>> 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?

Rename the helpers please.

A memory section has a size (which is a power of two / order). The page order
used inside the section should be clearly separated.

BTW, I didn't mention it yet, but I really enjoy this cleanup.

-- 
Cheers,

David