> On Jun 14, 2026, at 17:55, Mike Rapoport <[email protected]> wrote:
>
> 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.
Make sense. A followup rework is better.
Thanks.
>
>> Thanks.
>
> --
> Sincerely yours,
> Mike.
