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
