Re: [PATCHv6 05/17] riscv/mm: Align vmemmap to maximal folio size

David Hildenbrand (arm)
2026-02-04T16:50:31Z

On 2/2/26 16:56, Kiryl Shutsemau wrote:
> The upcoming change to the HugeTLB vmemmap optimization (HVO) requires
> struct pages of the head page to be naturally aligned with regard to the
> folio size.
>
> Align vmemmap to MAX_FOLIO_NR_PAGES.

I think neither that statement nor the one in the patch description is
correct?

"MAX_FOLIO_NR_PAGES * sizeof(struct page)" is neither the maximum folio
size nor MAX_FOLIO_NR_PAGES.

It's the size of the memmap that a large folio could span at maximum.

Assuming we have a 16 GiB folio, the calculation would give us

4194304 * sizeof(struct page)

Which could be something like (assuming 80 bytes)

335544320

-> not even a power of 2, weird? (for HVO you wouldn't care as HVO would
be disabled, but that aliment is super weird?)

Assuming 64 bytes, it would be a power of two (as 64 is a power of two).

268435456 (1<< 28)

Which makes me wonder whether there is a way to avoid sizeof(struct
page) here completely.

Or limit the alignment to the case where HVO is actually active and
sizeof(struct page) makes any sense?

>
> Signed-off-by: Kiryl Shutsemau <kas@kernel.org>
> ---
> arch/riscv/mm/init.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/arch/riscv/mm/init.c b/arch/riscv/mm/init.c
> index 21d534824624..c555b9a4fdce 100644
> --- a/arch/riscv/mm/init.c
> +++ b/arch/riscv/mm/init.c
> @@ -63,7 +63,8 @@ phys_addr_t phys_ram_base __ro_after_init;
> EXPORT_SYMBOL(phys_ram_base);
>
> #ifdef CONFIG_SPARSEMEM_VMEMMAP
> -#define VMEMMAP_ADDR_ALIGN (1ULL << SECTION_SIZE_BITS)
> +#define VMEMMAP_ADDR_ALIGN max(1ULL << SECTION_SIZE_BITS, \
> + MAX_FOLIO_NR_PAGES * sizeof(struct page))
>
> unsigned long vmemmap_start_pfn __ro_after_init;
> EXPORT_SYMBOL(vmemmap_start_pfn);

--
Cheers,

David