Re: [RFC PATCH 0/5] Separate compound page from folio

[Zi Yan]

On 20 Mar 2026, at 6:21, David Hildenbrand (Arm) wrote:

> On 1/30/26 04:48, Zi Yan wrote:
>> Hi all,
>
> Hi,
>
> sorry for only going over that now.
>
>>
>> Based on my discussion with Jason about device private folio
>> reinitialization[1], I realize that the concepts of compound page and folio
>> are mixed together and confusing, as people think a compound page is equal
>> to a folio. This is not true, since a compound page means a group of
>> pages is managed as a whole and it can be something other than a folio,
>> for example, a slab page. To avoid further confusing people, this
>> patchset separates compound page from folio by moving any folio related
>> code out of compound page functions.
>>
>> The code is on top of mm-new (2026-01-28-20-27) and all mm selftests
>> passed.
>>
>> The key change is that a compound page no longer sets:
>> 1. folio->_nr_pages,
>> 2. folio->_large_mapcount,
>> 3. folio->_nr_pages_mapped,
>> 4. folio->_mm_ids,
>> 5. folio->_mm_id_mapcount,
>> 6. folio->_pincount,
>> 7. folio->_entire_mapcount,
>> 8. folio->_deferred_list.
>
> Noble goal! :)
>
> As discussed, the issue is still that interpret non-folio page
> allocations as folios, which can also be compound pages.
>
> Now, there are PFN walkers that do that, but also page table handling code.
>
> Most prominently, when mapping such pages through vm_insert_pages(), we
> will call into folio_add_file_rmap_pte() and essentially touch mapcount
> related stuff.
>
> Once in the page tables, users can GUP them and modify the pincount.
> Other page table walkers can just similarly find them and look them up.
>
> To stop messing with mapcounts is easy once we can reliably identify
> such pages when mapping/unmapping them.

My current way of doing that is to mark every page “NotRmappable” page_type
in post_alloc_hook() and clear this page_type at page_rmappable_folio().
Any user wants to set their own page_type can overwrite “NotRmappable”.
And folio_test_rmappable() is just !folio_has_type(). One exception
is hugetlb, since it has page_type and is rmappable. Fortunately or
unfortunately, rmap.c has special handling code for hugetlb, so there
should be no problem.

I did some test using io_uring (via nvim), which uses compound page instead of
folio and does vm_insert*(). At least no crash was present.

>
> GUP and other page table walkers are more problematic and need more
> thought (and work :( ).
>
> Essentially, vm_normal_folio() would have to fail on these pages. But
> what to do about vm_normal_page() users? The page_folio() would have to
> fail. But then we must keep some page table walkers working.
>
> And we have to figure out what to do with GUP.

Since _pincount will not be present after my change, GUP cannot be applied
on these pages.

OK, my memory comes back. I think my original proposal of separating
compound page from folio might not be right, since that defeats the
purpose of folio, which is a group of pages managed as a whole.

Basically a compound page should still be regarded as a folio, but rmappable
related fields (e.g., _large_mapcount, _nr_pages_mapped, _mm_ids)
should not be initialized and user is free to use them differently.
In this way, _pincount can be a common folio field to initialize and use.

>
> So compound pages are just the tip of the iceberg :)
>
>
> We could maybe forbid mapping them through vm_insert_pages() in the
> first place, requiring all callers to do order-0 page allocations. Hm.
>
> Then at least they would not end up in user page tables.

Will it kill performance? If only order-0 pages are allowed.

>
> But there is other code where compound pages are interpreted as folios
> and the other way around that must be sorted out.

I think we might want to have some sub-class of folios, like rmappable folios,
not rmappable folios, and others, otherwise, we are going back
to mixing page and folio.


Best Regards,
Yan, Zi