Re: [PATCHv6 05/17] riscv/mm: Align vmemmap to maximal folio size
From: David Hildenbrand (Arm)
Date: Thu Feb 05 2026 - 08:59:26 EST
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.
Ah, and now I remember that sizeof cannot be used in macros, damnit.
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.
--
Cheers,
David