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

[Mike Rapoport]

On Wed, Jul 15, 2026 at 02:42:56PM +0800, Muchun Song wrote:
> 
> 
> > 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?
 
LGTM, thanks!
 
> >> + 	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.
> 
> 

-- 
Sincerely yours,
Mike.