Re: [PATCH 02/17] mm/sparse-vmemmap: track compound page order in struct mem_section

[Muchun Song]

> On Jul 15, 2026, at 13:08, Mike Rapoport <rppt@xxxxxxxxxx> wrote:
> 
>> HugeTLB and DAX both rely on vmemmap optimization, but sparsemem does
>> not record what compound page order a section is populated with.
>> 
>> As a result, code that needs this information has to open-code
>> separate handling across users of vmemmap optimization.  It also
>> prevents other memory management code, such as struct page
>> initialization, from skipping initialization of shared vmemmap pages
>> when needed.
>> 
>> Track the compound page order in struct mem_section and provide small
>> helpers to access it.  A compound page larger than a section naturally
>> carries the same order across all covered sections.
>> 
>> This is a preparatory change for consolidating vmemmap optimization
>> handling and for letting later code make initialization decisions
>> based on the section's compound page order.
>> 
>> Signed-off-by: Muchun Song <songmuchun@xxxxxxxxxxxxx>
>> 
>> diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
>> index 1353bcf7b712..bacd89572c5c 100644
>> --- a/include/linux/mmzone.h
>> +++ b/include/linux/mmzone.h
>> @@ -2015,6 +2015,14 @@ struct mem_section {
>>  */
>> struct page_ext *page_ext;
>> #endif
>> +#ifdef CONFIG_SPARSEMEM_VMEMMAP
>> + 	/*
>> + 	 * The order of compound pages in this section. Typically, the section
>> + 	 * holds compound pages of this order; a larger compound page will span
>> + 	 * multiple sections.
>> + 	 */
> 
> Typically a section holds order-0 pages ;-)
> 
> I think this comment should mention that this is for special sections,
> like hugetlb and DAX.

I will update the comment to focus on the general concept of HVO as follows:

	Normally, sections hold regular (order-0) pages. However, for
	sections with HVO enabled, this tracks the compound page order
	to enable deduplication of redundant vmemmap pages.

How does this look to you?

> 
>> + 	unsigned int order;
>> +#endif
>> };
>> 
>> #ifdef CONFIG_SPARSEMEM_EXTREME
>> @@ -2361,10 +2369,34 @@ static inline unsigned long next_present_section_nr(unsigned long section_nr)
>> #endif
>> 
>> #else
>> +struct mem_section;
>> +
>> #define sparse_vmemmap_init_nid_early(_nid) do {} while (0)
>> #define pfn_in_present_section pfn_valid
>> #endif /* CONFIG_SPARSEMEM */
>> 
>> +#ifdef CONFIG_SPARSEMEM_VMEMMAP
>> +static inline void section_set_order(struct mem_section *section, unsigned int order)
>> +{
>> + 	VM_WARN_ON(section->order && order && section->order != order);
>> + 	section->order = order;
>> +}
>> +
>> +static inline unsigned int section_order(const struct mem_section *section)
>> +{
>> + 	return section->order;
>> +}
> 
> You mention open-coded handling, is there any open-coded case that can
> be replaced with the new helpers right away?

The term "open-code" in my commit message might not have been clear enough.

What I intended to convey is that because HVO lacks this specific layer of
information in both DAX and HugeTLB scenarios, they each handle their own
cases independently. As a result, there isn't enough code reuse.

Thank you so much for pointing that out.

> 
> We strive to have new APIs and at least some of their users in the same
> patch.

All right. Starting with the next version, I'll be introducing the necessary
fields (i.e. ->order) or interfaces here into each of the upcoming patches.
In that case, this patch should no longer exist.

Muchun,
Thanks.

> 
> -- 
> Sincerely yours,
> Mike.