Message-ID: <33B161E0-5468-4A31-A5BC-B4F1FCE72CEC@nvidia.com>
Date: Wed, 04 Feb 2026 13:29:45 -0500
From: Zi Yan <ziy@...dia.com>
To: Balbir Singh <balbirs@...dia.com>
Cc: Jason Gunthorpe <jgg@...dia.com>, David Hildenbrand <david@...nel.org>,
 Matthew Wilcox <willy@...radead.org>, Alistair Popple <apopple@...dia.com>,
 Andrew Morton <akpm@...ux-foundation.org>,
 Lorenzo Stoakes <lorenzo.stoakes@...cle.com>,
 "Liam R. Howlett" <Liam.Howlett@...cle.com>,
 Vlastimil Babka <vbabka@...e.cz>, Mike Rapoport <rppt@...nel.org>,
 Suren Baghdasaryan <surenb@...gle.com>, Michal Hocko <mhocko@...e.com>,
 Jens Axboe <axboe@...nel.dk>, Baolin Wang <baolin.wang@...ux.alibaba.com>,
 Nico Pache <npache@...hat.com>, Ryan Roberts <ryan.roberts@....com>,
 Dev Jain <dev.jain@....com>, Barry Song <baohua@...nel.org>,
 Lance Yang <lance.yang@...ux.dev>, Muchun Song <muchun.song@...ux.dev>,
 Oscar Salvador <osalvador@...e.de>, Brendan Jackman <jackmanb@...gle.com>,
 Johannes Weiner <hannes@...xchg.org>, <linux-mm@...ck.org>,
 <linux-kernel@...r.kernel.org>, <io-uring@...r.kernel.org>
Subject: Re: [RFC PATCH 0/5] Separate compound page from folio

On 4 Feb 2026, at 11:21, Zi Yan wrote:

> On 2 Feb 2026, at 23:30, Balbir Singh wrote:
>
>> 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?
>
> Yes. All folio initialization code is moved from prep_compound_page() to
> page_rmappable_folio(), so such users will see warnings on some folio fields
> are not set properly. They should call page_rmappable_folio() on compound
> pages they are planning to use as folios. A common use case is to
> vm_insert_page(s)() on subpages of a folio.
>
> For in-tree users, I am converting them all in this series.

Considering a recent report[1], where drivers/scsi/sg.c allocates compound
pages with __GFP_COMP and maps them into userspace via sg_vma_fault(),
I guess almost all __GFP_COMP users are really using folios instead of
compound pages.


[1] https://lore.kernel.org/all/PS1PPF7E1D7501F1E4F4441E7ECD056DEADAB98A@PS1PPF7E1D7501F.apcprd02.prod.outlook.com/

>
>>
>>>
>>>
>>> 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(-)
>>>
>
>
> Best Regards,
> Yan, Zi


Best Regards,
Yan, Zi

Powered by blists - more mailing lists