Re: [PATCH 2/3] mm/page_ext: support early allocation for SPARSEMEM

[Muchun Song <muchun.song@linux.dev>]

> On Nov 15, 2026, at 15:31, Mike Rapoport <rppt@kernel.org> wrote:
> 
> Hi Muchun,

Hi Mike,

> 
>> Moving KMSAN's per-page metadata into page_ext requires page extensions
>> to be available when kmsan_init_shadow() runs, before memblock is freed.
>> FLATMEM page extensions are available by then, but SPARSEMEM normally
>> allocates them later from the page or vmalloc allocators.
>> 
>> Add need_early so clients can request SPARSEMEM section backing from
>> memblock during page_ext_init_early().
> 
> Can't we just always allocate page_ext for early sections from memblock?

That would be simpler. I checked the page_ext history but could not find a
documented reason for treating boot-time SPARSEMEM sections differently or
for avoiding memblock allocation there.

I agree with your suggestion. I will remove need_early and allocate
page_ext from memblock for boot-time SPARSEMEM sections whenever any client
needs it.

> 
>> Use page_ext_init() as the common late path for client callbacks.
>> KMSAN starts requesting early page extensions in the following patch.
>> 
>> Signed-off-by: Muchun Song <songmuchun@bytedance.com>
>> ---
>> include/linux/page_ext.h | 26 +++--------
>> mm/mm_init.c             | 11 +----
>> mm/page_ext.c            | 99 ++++++++++++++++++++++++++++++----------
>> 3 files changed, 82 insertions(+), 54 deletions(-)
>> 
>> +static __ref void *alloc_page_ext(size_t size, int nid)
>> {
>> 	gfp_t flags = GFP_KERNEL | __GFP_ZERO | __GFP_NOWARN;
>> 	void *addr = NULL;
>> 
>> +	if (!slab_is_available()) {
>> +	addr = memblock_alloc_try_nid(size, PAGE_SIZE, 0,
>> +       			      MEMBLOCK_ALLOC_ACCESSIBLE, nid);
>> +	if (addr)
>> +		memmap_boot_pages_add(size / PAGE_SIZE);
>> +		return addr;
>> +	}
>> +
>> 	addr = alloc_pages_exact_nid(nid, size, flags);
> 
> And unrelated to this patch, do we really need to try an allocation from
> buddy rather than always use vmalloc?
> 

From my perspective, I don't think it's necessary at all. The only real
benefit to allocating from the buddy might be better performance compared
to vmalloc, but do we actually care about performance here? It doesn't look
like this is on the hot path, so I don't think it's necessary. We can remove
it to simplify the code. I can make that a separate cleanup.

Thanks,
Muchun

> -- 
> Sincerely yours,
> Mike.