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

Kiryl Shutsemau
2026-02-05T13:50:28Z

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