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

[David Laight <david.laight.linux@gmail.com>]

On Thu,  2 Jul 2026 17:38:06 +0800
Muchun Song <songmuchun@bytedance.com> 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@bytedance.com>
> ---
>  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.
 
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.

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.

	David