Re: [PATCH v3 3/7] mm: Split device-private and coherent folios before freeing

[Matthew Brost]

On Fri, Jan 09, 2026 at 01:53:33PM -0500, Zi Yan wrote:
> 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 <matthew.brost@xxxxxxxxx>
> >>>>
> >>>> 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 <balbirs@xxxxxxxxxx>
> >>>> Cc: Alistair Popple <apopple@xxxxxxxxxx>
> >>>> Cc: Zi Yan <ziy@xxxxxxxxxx>
> >>>> Cc: David Hildenbrand <david@xxxxxxxxxx>
> >>>> Cc: Oscar Salvador <osalvador@xxxxxxx>
> >>>> Cc: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
> >>>> Cc: linux-mm@xxxxxxxxx
> >>>> Cc: linux-cxl@xxxxxxxxxxxxxxx
> >>>> Cc: linux-kernel@xxxxxxxxxxxxxxx
> >>>> Signed-off-by: Matthew Brost <matthew.brost@xxxxxxxxx>
> >>>> Signed-off-by: Francois Dugast <francois.dugast@xxxxxxxxx>
> >>>> ---
> >>>>  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.
> 

I agree it is asymmetric and symmetric is likely better.

> 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

The way Nouveau handles memory allocations here looks wrong to me—it
should probably use DRM Buddy and convert a block buddy to pages rather
than tracking a free folio list and free page list. But this is not my
driver.

> is wrong by calling prep_compound_page() on a folio (already compound page).
>

I don’t disagree that this implementation is questionable.

So what’s the suggestion here—add folio order to folio_free just to
accommodate Nouveau’s rather odd memory allocation algorithm? That
doesn’t seem right to me either.

Matt
 
> Best Regards,
> Yan, Zi