Re: [PATCHv6 06/17] LoongArch/mm: Align vmemmap to maximal folio size
From: David Hildenbrand (Arm)
Date: Thu Feb 05 2026 - 08:52:39 EST
On 2/5/26 14:43, Kiryl Shutsemau wrote:
On Thu, Feb 05, 2026 at 01:56:36PM +0100, David Hildenbrand (Arm) wrote:
On 2/4/26 17:56, David Hildenbrand (arm) wrote:
Same comment, the "MAX_FOLIO_NR_PAGES * sizeof(struct page)" is just
black magic here
and the description of the situation is wrong.
Maybe you want to pull the magic "MAX_FOLIO_NR_PAGES * sizeof(struct
page)" into the core and call it
#define MAX_FOLIO_VMEMMAP_ALIGN (MAX_FOLIO_NR_PAGES * sizeof(struct
page))
But then special case it base on (a) HVO being configured in an (b) HVO
being possible
#ifdef HUGETLB_PAGE_OPTIMIZE_VMEMMAP && is_power_of_2(sizeof(struct page)
/* A very helpful comment explaining the situation. */
#define MAX_FOLIO_VMEMMAP_ALIGN (MAX_FOLIO_NR_PAGES * sizeof(struct
page))
#else
#define MAX_FOLIO_VMEMMAP_ALIGN 0
#endif
Something like that.
Thinking about this ...
the vmemmap start is always struct-page-aligned. Otherwise we'd be in
trouble already.
Isn't it then sufficient to just align the start to MAX_FOLIO_NR_PAGES?
Let's assume sizeof(struct page) == 64 and MAX_FOLIO_NR_PAGES = 512 for
simplicity.
vmemmap start would be multiples of 512 (0x0010000000).
512, 1024, 1536, 2048 ...
Assume we have an 256-pages folio at 1536+256 = 0x111000000
s/0x/0b/, but okay.
:)
Assume we have the last page of that folio (0x011111111111), we would just
get to the start of that folio by AND-ing with ~(256-1).
Which case am I ignoring?
IIUC, you are ignoring the actual size of struct page. It is not 1 byte :P
I thought it wouldn't matter but, yeah, that's it.
"Align the vmemmap to the maximum folio metadata size" it is.
Then you can explain the situation also alongside MAX_FOLIO_VMEMMAP_ALIGN, and that we expect this to be a power of 2.
--
Cheers,
David