On 9 Jan 2026, at 13:26, Matthew Brost wrote: > On Fri, Jan 09, 2026 at 12:28:22PM -0500, Zi Yan wrote: >> On 9 Jan 2026, at 6:09, Mika Penttilä wrote: >> >>> Hi, >>> >>> On 1/9/26 10:54, Francois Dugast wrote: >>> >>>> From: Matthew Brost <[email protected]> >>>> >>>> Split device-private and coherent folios into individual pages before >>>> freeing so that any order folio can be formed upon the next use of the >>>> pages. >>>> >>>> Cc: Balbir Singh <[email protected]> >>>> Cc: Alistair Popple <[email protected]> >>>> Cc: Zi Yan <[email protected]> >>>> Cc: David Hildenbrand <[email protected]> >>>> Cc: Oscar Salvador <[email protected]> >>>> Cc: Andrew Morton <[email protected]> >>>> Cc: [email protected] >>>> Cc: [email protected] >>>> Cc: [email protected] >>>> Signed-off-by: Matthew Brost <[email protected]> >>>> Signed-off-by: Francois Dugast <[email protected]> >>>> --- >>>> mm/memremap.c | 2 ++ >>>> 1 file changed, 2 insertions(+) >>>> >>>> diff --git a/mm/memremap.c b/mm/memremap.c >>>> index 63c6ab4fdf08..7289cdd6862f 100644 >>>> --- a/mm/memremap.c >>>> +++ b/mm/memremap.c >>>> @@ -453,6 +453,8 @@ void free_zone_device_folio(struct folio *folio) >>>> case MEMORY_DEVICE_COHERENT: >>>> if (WARN_ON_ONCE(!pgmap->ops || !pgmap->ops->folio_free)) >>>> break; >>>> + >>>> + folio_split_unref(folio); >>>> pgmap->ops->folio_free(folio); >>>> percpu_ref_put_many(&folio->pgmap->ref, nr); >>>> break; >>> >>> This breaks folio_free implementations like nouveau_dmem_folio_free >>> which checks the folio order and act upon that. >>> Maybe add an order parameter to folio_free or let the driver handle the >>> split? > > 'let the driver handle the split?' - I had consisder this as an option. > >> >> Passing an order parameter might be better to avoid exposing core MM >> internals >> by asking drivers to undo compound pages. >> > > It looks like Nouveau tracks free folios and free pages—something Xe’s > device memory allocator (DRM Buddy) cannot do. I guess this answers my > earlier question of how Nouveau avoids hitting the same bug as Xe / GPU > SVM with respect to reusing folios. It appears Nouveau prefers not to > split the folio, so I’m leaning toward moving this call into the > driver’s folio_free function.
No, that creates asymmetric page handling and is error prone. In addition, looking at nouveau’s implementation in nouveau_dmem_page_alloc_locked(), it gets a folio from drm->dmem->free_folios, which is never split, and passes it to zone_device_folio_init(). This is wrong, since if the folio is large, it will go through prep_compound_page() again. The bug has not manifested because there is only order-9 large folios. Once mTHP support is added, how is nouveau going to allocate a order-4 folio from a free order-9 folio? Maintain a per-order free folio list and reimplement a buddy allocator? Nevertheless, nouveau’s implementation is wrong by calling prep_compound_page() on a folio (already compound page). Best Regards, Yan, Zi
