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.

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);
-- 
2.51.2

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

On Wed, Feb 04, 2026 at 05:50:23PM +0100, David Hildenbrand (arm) wrote:
> 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.

I don't think we can. See the other thread.

What about using roundup_pow_of_two(sizeof(struct page)) here.

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

The annoying part of HVO is that it is unknown at compile-time if it
will be used. You can compile kernel with HVO that will no be activated
due to non-power-of-2 sizeof(struct page) because of a debug config option.

-- 
  Kiryl Shutsemau / Kirill A. Shutemov

On 2/5/26 14:50, Kiryl Shutsemau wrote:
> On Wed, Feb 04, 2026 at 05:50:23PM +0100, David Hildenbrand (arm) wrote:
>> 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.
> 
> I don't think we can. See the other thread.

Agreed. You could only go for something larger (like PAGE_SIZE).

> 
> What about using roundup_pow_of_two(sizeof(struct page)) here.

Better I think.

> 
>> Or limit the alignment to the case where HVO is actually active and
>> sizeof(struct page) makes any sense?
> 
> The annoying part of HVO is that it is unknown at compile-time if it
> will be used. You can compile kernel with HVO that will no be activated
> due to non-power-of-2 sizeof(struct page) because of a debug config option.
Ah, and now I remember that sizeof cannot be used in macros, damnit.

-- 
Cheers,

David