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 <[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. >
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
