Re: [PATCH v1 1/2] mm/huge_memory: introduce uniform_split_unmapped_folio_to_zero_order

[Zi Yan <ziy@nvidia.com>]

On 16 Nov 2025, at 22:15, Harry Yoo wrote:

> On Sun, Nov 16, 2025 at 11:51:14AM +0000, Matthew Wilcox wrote:
>> On Sun, Nov 16, 2025 at 01:47:20AM +0000, Jiaqi Yan wrote:
>>> Introduce uniform_split_unmapped_folio_to_zero_order, a wrapper
>>> to the existing __split_unmapped_folio. Caller can use it to
>>> uniformly split an unmapped high-order folio into 0-order folios.
>>
>> Please don't make this function exist.  I appreciate what you're trying
>> to do, but let's try to do it differently?
>>
>> When we have struct folio separately allocated from struct page,
>> splitting a folio will mean allocating new struct folios for every
>> new folio created.  I anticipate an order-0 folio will be about 80 or
>> 96 bytes.  So if we create 512 * 512 folios in a single go, that'll be
>> an allocation of 20MB.
>>
>> This is why I asked Zi Yan to create the asymmetrical folio split, so we
>> only end up creating log() of this.  In the case of a single hwpoison page
>> in an order-18 hugetlb, that'd be 19 allocations totallying 1520 bytes.
>
> Oh god, I completely overlooked this aspect when discussing this with Jiaqi.
> Thanks for raising this concern.
>
>> But since we're only doing this on free, we won't need to do folio
>> allocations at all; we'll just be able to release the good pages to the
>> page allocator and sequester the hwpoison pages.
>
> [+Cc PAGE ALLOCATOR folks]
>
> So we need an interface to free only healthy portion of a hwpoison folio.
>
> I think a proper approach to this should be to "free a hwpoison folio
> just like freeing a normal folio via folio_put() or free_frozen_pages(),
> then the page allocator will add only healthy pages to the freelist and
> isolate the hwpoison pages". Oherwise we'll end up open coding a lot,
> which is too fragile.

Why not use __split_unmaped_folio(folio, /*new_order=*/0,
								  /split_at=*/HWPoisoned_page,
								  ..., /*uniform_split=*/ false)?

If there are multiple HWPoisoned pages, just repeat.

>
> In fact, that can be done by teaching free_pages_prepare() how to handle
> the case where one or more subpages of a folio are hwpoison pages.
>
> How this should be implemented in the page allocator in memdescs world?
> Hmm, we'll want to do some kind of non-uniform split, without actually
> splitting the folio but allocating struct buddy?
>
> But... for now I think hiding this complexity inside the page allocator
> is good enough. For now this would just mean splitting a frozen page
> inside the page allocator (probably non-uniform?). We can later re-implement
> this to provide better support for memdescs.
>
> -- 
> Cheers,
> Harry / Hyeonggon


--
Best Regards,
Yan, Zi