Re: [PATCH v3 14/19] mm/hugetlb: Free cross-zone bootmem gigantic pages after allocation

[Muchun Song]

> On Jun 2, 2026, at 23:41, Mike Rapoport <rppt@xxxxxxxxxx> wrote:
> 
> On Tue, 02 Jun 2026 18:10:34 +0800, Muchun Song <songmuchun@xxxxxxxxxxxxx> wrote:
> 
> Hi Muchun,

Hi Mike,

> 
>> 
>> diff --git a/mm/hugetlb.c b/mm/hugetlb.c
>> index 5e557c05d80a..218fb1ca45f4 100644
>> --- a/mm/hugetlb.c
>> +++ b/mm/hugetlb.c
>> @@ -3073,22 +3076,38 @@ static bool __init alloc_bootmem_huge_page(struct hstate *h, int nid)
>> [ ... skip 26 lines ... ]
>> + 	* pages belonging to the requested node.
>> + 	*/
>> + 	if (WARN_ON_ONCE(nid_request != NUMA_NO_NODE && nid != nid_request))
>> + 		list_add(&m->list, &huge_boot_pages[nid_request]);
>> + 	else
>> + 		list_add(&m->list, &huge_boot_pages[nid]);
> 
> Can we just memblock_free() the page that intersects zones here?

I had previously considered doing this, but then I realized that if we free the
allocated cross-zone memory here, memblock is very likely to select the exact
same block for the next allocation. This means we'd just end up with this
cross-zone memory again, degrading allocation efficiency. Unless there is a way
to mark the block so memblock avoids reallocating it, I ultimately chose to
defer the release to prevent this issue from happening.

Thanks.

> 
> Rather than making alloc_bootmem_huge_page() bool (sorry my bad :)) we
> can make it return -ENOMEM when memblock_alloc() fails, 0 if the page is
> not usable and 1 (i.e. number of allocated gigantic pages) if everything
> is fine.
> 
> The callers would need a bit of massage, but it still seems simpler to
> me than adding them to the list and then walking that list.
> 
> -- 
> Sincerely yours,
> Mike.
>