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

[Muchun Song]

> On Jul 16, 2026, at 17:15, David Laight <david.laight.linux@xxxxxxxxx> wrote:
> 
> On Thu,  2 Jul 2026 17:38:06 +0800
> Muchun Song <songmuchun@xxxxxxxxxxxxx> 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>
>> ---
>> include/linux/mmzone.h | 32 ++++++++++++++++++++++++++++++++
>> 1 file changed, 32 insertions(+)
>> 
>> 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.
>> + 	 */
>> + 	unsigned int order;
>> +#endif
>> };
> 
> That increases the size of the structure by 8 bytes for a value that
> would fit in one (or 16 bytes to maintain power-of-2 size).
> I'm pretty sure this array is big - so that is significant.
> 
> I've looked up some constants...
> On x86-64 each section is (1 << 27) bytes or 128M.
> A page contains 256 small 'struct mm_section' so covers 32GB of physical address.
> That is pretty much the memory limit for a 'normal' system.
> So even doubling the structure size only uses 2 pages for 32GB memory.
> Even packing the structure (or making it 48 bytes) would still use 2 pages.
> Of course there are the big servers with TB of memory...
> 
> A more interesting problem is the size of the 'page pointer' array.
> That is sized for physical addresses right at the top of the 52bits
> supported by 5-level page tables.
> I make that 52-27-8+3 = 20 bits or 1MB, doubling to 2MB if struct mem_section
> is increased to 32 bytes.
> However, in practise, I suspect that the actual upper limit for physical
> addresses is much lower.

That was a truly excellent analysis. It is clear that the memory used by the
mem_section occupies a very small percentage of the overall system memory.

> 
> It is also worth noting that CONFIG_PAGE_EXTENSION is a debug option.
> It probably doesn't matter about efficiency if it is enabled.
> 
> You could change the code to use % instead of & - makes no difference if
> the size is a power of 2. That is generally safer.

No problem. My patch 1 has already handled that.

> 
> Then do:
> #if defined(CONFIG_PAGE_EXTENSION) || defined (CONFIG_SPARSEMEM_VMEMMAP)
> 	struct page_ext *page_ext;
> 	unsigned int order;
> #endif
> With an extra comment about keeping power of 2 size for effifiency.

Thanks for the suggestion! I'll use this approach to ensure men_section
is aligned to a power of two again. I'll also add a comment here to explain
the reasoning behind this implementation.

I really appreciate your detailed analysis and insights.

Muchun,
Thanks.

> 
> David