Re: [PATCH 04/17] mm/mm_init: skip initializing shared vmemmap tail pages

[Muchun Song]

> On Jul 9, 2026, at 18:45, Mike Rapoport <rppt@xxxxxxxxxx> wrote:
> 
> Hi Muchun,

Hi,

> 
> Below are some preliminary comments, I'm planning to spend more time on
> review next week.

Thanks for the early feedback! Looking forward to more review next week.

> 
> On Thu, Jul 02, 2026 at 05:38:08PM +0800, Muchun Song wrote:
>> memmap_init_range() initializes every struct page in the target range.
>> For compound pages with vmemmap optimization, the tail struct pages are
>> backed by a shared vmemmap page.
>> 
>> Initializing those tail struct pages would overwrite the shared
>> vmemmap page contents, so users such as HugeTLB have to open-code
>> follow-up handling to restore the metadata afterwards.
>> 
>> Use the section's compound page order to detect struct pages that fall
>> into the shared tail vmemmap range and skip their initialization in
>> memmap_init_range().  Still initialize the pageblock migratetypes for
>> the skipped range so the surrounding setup remains intact.
>> 
>> This is a preparatory change for consolidating handling across users of
>> vmemmap optimization, and it also avoids redundant initialization of
>> shared tail vmemmap pages during early boot.
>> 
>> Signed-off-by: Muchun Song <songmuchun@xxxxxxxxxxxxx>
>> ---
>> include/linux/mmzone.h |  4 ++++
>> mm/internal.h          | 16 ++++++++++++++++
>> mm/mm_init.c           | 25 +++++++++++++++++++------
>> 3 files changed, 39 insertions(+), 6 deletions(-)
>> 
>> @@ -673,19 +673,21 @@ static inline void fixup_hashdist(void)
>> static inline void fixup_hashdist(void) {}
>> #endif /* CONFIG_NUMA */
>> 
>> -#if defined(CONFIG_ZONE_DEVICE) || defined(CONFIG_DEFERRED_STRUCT_PAGE_INIT)
>> static __meminit void pageblock_migratetype_init_range(unsigned long pfn,
>> - unsigned long nr_pages, int migratetype, bool atomic)
>> + unsigned long nr_pages, int migratetype, bool isolate, bool atomic)
> 
> What is isolate parameter for?

I've re-examined the code, and you're right that the isolate parameter is technically
redundant for our current use case, as memmap_init_zone_range() passes false.

The rationale behind keeping it is future-proofing. The ultimate goal of a generic
HVO is to support arbitrary huge pages, not just HugeTLB. I decoupled this as a
parameter to prevent potential regressions down the road; if a developer leverages
this for other huge page types in the future, they won't inadvertently break
things by forgetting to update a hardcoded false in init_pageblock_migratetype(),
especially since memmap_init_range() natively accepts an isolate parameter.

Of course, we could also just delete this parameter for now and add it back later if
needed. I think both approaches work.

Which way are you leaning?

> 
>> {
>> 	const unsigned long end = pfn + nr_pages;
>> 
>> 	for (pfn = pageblock_align(pfn); pfn < end; pfn += pageblock_nr_pages) {
>> - 		init_pageblock_migratetype(pfn_to_page(pfn), migratetype, false);
>> + 		init_pageblock_migratetype(pfn_to_page(pfn), migratetype, isolate);
>> +#ifdef CONFIG_SPARSEMEM
>> 		if (!atomic && IS_ALIGNED(pfn, PAGES_PER_SECTION))
>> +#else
>> + 		if (!atomic && IS_ALIGNED(pfn, MAX_FOLIO_NR_PAGES))
>> +#endif
> 
> Let's trigger cond_resched() on some defined number of iterations or some
> memory size chunk, e.g PAGES_PER_128M or even PAGES_PER_1G.

Yes, that's for the best. I was really struggling to choose a suitable macro
for this earlier, but I realized it's a difficult thing to get right. I'm leaning
toward selecting PAGES_PER_1G instead.

Muchun,
Thanks.

> 
>> 			cond_resched();
>> 	}
>> }
> 
> -- 
> Sincerely yours,
> Mike.