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

[Lorenzo Stoakes (ARM)]

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.

>
> 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.

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.

> >
> > 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.

>
> --
> Cheers,
>
> David

Cheers, Lorenzo