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

[Balbir Singh <balbirs@nvidia.com>]

On 1/30/26 14:48, Zi Yan wrote:
> Hi all,
> 
> 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.
> 
> Since these fields are only used by folios that are rmappable. The code
> setting these fields is moved to page_rmappable_folio(). To make the
> code move, this patchset also needs to changes several places, where
> folio and compound page are used interchangably or unusual folio use:
> 
> 1. in io_mem_alloc_compound(), a compound page is allocated, but later
>    it is mapped via vm_insert_pages() like a rmappable folio;
> 2. __split_folio_to_order() sets large_rmappable flag directly instead
>    of using page_rmappable_folio() for after-split folios;
> 3. hugetlb unsets large_rmappable to escape deferred_list unqueue
>    operation.
> 
> At last, the page freeing path is also changed to have different checks
> for compound page and folio.
> 

Thanks for doing this! 


> One thing to note is that for compound page, I do not store compound
> order in folio->_nr_pages, which overlaps with page[1].memcg_data and
> use 1 << compound_order() instead, since I do not want to add a new
> union to struct page and compound_nr() is not as widely used as
> folio_nr_pages(). But let me know if there is a performance concern for
> this.
> 
> Comments and suggestions are welcome.
> 

What does this mean for treating compound pages as folios, does this break
code that makes any assumptions about their interop?

> 
> 
> Link: https://lore.kernel.org/all/F7E3DF24-A37B-40A0-A507-CEF4AB76C44D@nvidia.com/ [1]
> 
> Zi Yan (5):
>   io_uring: allocate folio in io_mem_alloc_compound() and function
>     rename
>   mm/huge_memory: use page_rmappable_folio() to convert after-split
>     folios
>   mm/hugetlb: set large_rmappable on hugetlb and avoid deferred_list
>     handling
>   mm: only use struct page in compound_nr() and compound_order()
>   mm: code separation for compound page and folio
> 
>  include/linux/mm.h | 12 ++++--------
>  io_uring/memmap.c  | 12 ++++++------
>  mm/huge_memory.c   |  5 ++---
>  mm/hugetlb.c       |  8 ++++----
>  mm/hugetlb_cma.c   |  2 +-
>  mm/internal.h      | 47 +++++++++++++++++++++++++++-------------------
>  mm/mm_init.c       |  2 +-
>  mm/page_alloc.c    | 23 ++++++++++++++++++-----
>  8 files changed, 64 insertions(+), 47 deletions(-)
>