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

[David Hildenbrand (arm)]

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 at 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