Re: [PATCH 1/3] mm/huge_memory: add folio_split_driver_managed()

[Zi Yan <ziy@nvidia.com>]

On 28 Jul 2026, at 10:44, Lorenzo Stoakes (ARM) wrote:

> On Tue, Jul 28, 2026 at 02:58:39PM +0200, David Hildenbrand (Arm) wrote:
>> On 7/27/26 20:23, Zi Yan wrote:
>>> On 27 Jul 2026, at 13:33, David Hildenbrand (Arm) wrote:
>>>
>>>> On 7/22/26 17:28, Zi Yan wrote:
>>>>>
>>>>> Strickly speaking, these vm_insert*() compound pages are not folios,
>>>>> since folios are supposed to be rmappable and they are either anonymous
>>>>> memory or file-backed memory. I am working on separating them from
>>>>> rmappable folios by replacing PG_private with PG_folio and marking all
>>>>> pages in a folio with PG_folio in page_rmappable_folio().
>>>>>
>>>>> Hopefully, we can find a better name, like refcounted_folio, later for
>>>>> these non-rmappable compound pages.
>>>>
>>>> They wouldn't really be folios, I guess. They would likely be a simple
>>>> "refcounted" memtype that allows for compound pages.
>>>
>>> Yes, they are not folios. But “folio” was started to replace “compound page”
>>> and slowly becomes rmappable anon and file-backed. People outside MM still
>>> thinks “folio” == “compound page”.
>>
>> Yes, it's a bit of a mess now.
>>
>>> But once I manage to remove PG_private
>>> and get us PG_folio, page_folio() will return NULL for non-folio compound
>>> pages and we will need a new type for them, “refcounted_XXX”. We can decide
>>> XXX when I get there. :)
>>
>> So far willy did not document a type that just has a refcount.
>>
>> https://kernelnewbies.org/MatthewWilcox/Memdescs
>
> I was going to say.
>
> It seems a bit specific, because different things might have a different use for
> 'pages with refcounts that shouldn't be touched by core mm' and different
> semantics perhaps.
>
> Obviously if it was a different memdesc type then it'd not be a folio.

Yes, this part is easy. Slab uses GFP_COMP and no one regards large slab pages
as folios. The confusion comes from large pages without a page_type.

>
>>
>> Maybe "Managed memory" (struct mgdesc) could be the right thing for some memory
>> with a refcount.

For driver allocated memory, probably yes. I also see allocations listed below
with GFP_KERNEL_ACCOUNT | __GFP_COMP, so AcctMem would also be a candidate.

1. arch/s390/kvm/dat.c
2. io_uring/memmap.c
3. drivers/dma-buf/heaps/system_heap.c when mem_accounting is enabled.

>>
>> The question is, if the use case at hand would even require a refcount, of if
>> frozen pages would be good enough.

I hope so and that could simplify our work without handling refcount. But I assume
user outside MM would still want a refcount to do the page life time management
work, otherwise they might need to build their own one(s).

>>
>>>
>>>>
>>>> But what is the conclusion here? It sounds like "folio_split_" is the entirely
>>>> wrong interface for these compound pages.
>
> Yeah the thing is we need some clarification on what is a folio exactly.
>
> 	A folio is a physically, virtually and logically contiguous set of
> 	bytes.  It is a power-of-two in size, and it is aligned to that same
> 	power-of-two.  It is at least as large as %PAGE_SIZE.  If it is in the
> 	page cache, it is at a file offset which is a multiple of that
> 	power-of-two.  It may be mapped into userspace at an address which is at
> 	an arbitrary page offset, but its kernel virtual address is aligned to
> 	its size.
>
> By that definition a compound page _is_ a folio. And anything that _could_ be
> mapped into userland.
>
> But if we are going to say folio == rmappable then can we actually update the
> description of folio to say so?
>
> Or perhaps reference the fact that 'transitionally' it is as above, but in
> future will mean only rmappable.

I can come up with a patch clarifying the comment.

>
>>>
>>> We probably would allow folio_split() to be used on compound pages now
>>> until we can make a clean distinction, e.g., using PG_folio, between them.
>>>
>>> Yes, folio_split() and its helper functions are meant for rmappable anon and
>>> file-backed folios. But currently “folio” is de facto “compound page”, since
>>> for example prep_compound_head() initializes folio fields even if it is meant
>>> only for compound pages.
>>
>> If we can stop more abuse right from the start, that would be nice.
>
> Yes.
>
>>
>> We do have split_page() that splits a non-compound higher-order page. Maybe we
>> want a split_compound_page(), or allow for split_page() to accept compound pages.
>
> Ha! I read this after making this very same suggestion. High.. 5?
>
> But yeah obviously agree.
>
>>
>> Because splitting a folio is really something different than splitting just some
>> compound page (no mapping/pagecache/whatever involved).
>
> Yup.

It sounds like split_compound_page() gets some love (David, Lorenzo, and Matthew
all want it). I can add one to mm/page_alloc.c, so that Matthew can build
his patchset on top of it.


Best Regards,
Yan, Zi