On Wed, Jun 03, 2026 at 10:53:04AM +0800, Muchun Song wrote: > > On Tue, 02 Jun 2026 18:10:34 +0800, Muchun Song <[email protected]> > > 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.
