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
