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

[Mike Rapoport <rppt@kernel.org>]

On Wed, Jun 03, 2026 at 10:53:04AM +0800, Muchun Song wrote:
> > On Tue, 02 Jun 2026 18:10:34 +0800, Muchun Song <songmuchun@bytedance.com> wrote:
> >> 
> >> 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.

You are right, there's no simple way to avoid memblock using the same
range.

The comment at hugetlb_hstate_alloc_pages() hints that we might want to
split allocation of gigantic pages to be more explicit as a followup
rework and then freeing of cross-zone pages would be cleaner as well.
 
> Thanks.

-- 
Sincerely yours,
Mike.