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

[Matthew Wilcox <willy@infradead.org>]

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.

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.