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

["David Hildenbrand (Arm)" <david@kernel.org>]

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

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

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

> 
>>
>> But what is the conclusion here? It sounds like "folio_split_" is the entirely
>> wrong interface for these compound pages.
> 
> 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.

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.

Because splitting a folio is really something different than splitting just some
compound page (no mapping/pagecache/whatever involved).

-- 
Cheers,

David