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

[David Hildenbrand (Arm)]

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.

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.

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.

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

-- 
Cheers,

David