On 1/12/26 10:51, Zi Yan wrote: > On 11 Jan 2026, at 19:19, Balbir Singh wrote: > >> On 1/12/26 08:35, Matthew Wilcox wrote: >>> On Sun, Jan 11, 2026 at 09:55:40PM +0100, Francois Dugast wrote: >>>> The core MM splits the folio before calling folio_free, restoring the >>>> zone pages associated with the folio to an initialized state (e.g., >>>> non-compound, pgmap valid, etc...). The order argument represents the >>>> folio’s order prior to the split which can be used driver side to know >>>> how many pages are being freed. >>> >>> This really feels like the wrong way to fix this problem. >>> > > Hi Matthew, > > I think the wording is confusing, since the actual issue is that: > > 1. zone_device_page_init() calls prep_compound_page() to form a large folio, > 2. but free_zone_device_folio() never reverse the course, > 3. the undo of prep_compound_page() in free_zone_device_folio() needs to > be done before driver callback ->folio_free(), since once ->folio_free() > is called, the folio can be reallocated immediately, > 4. after the undo of prep_compound_page(), folio_order() can no longer provide > the original order information, thus, folio_free() needs that for proper > device side ref manipulation. > > So this is not used for "split" but undo of prep_compound_page(). It might > look like a split to non core MM people, since it changes a large folio > to a bunch of base pages. BTW, core MM has no compound_page_dctor() but > open codes it in free_pages_prepare() by resetting page flags, page->mapping, > and so on. So it might be why the undo prep_compound_page() is missed > by non core MM people. > >> >> This stems from a special requirement, freeing is done in two phases >> >> 1. Free the folio -> inform the driver (which implies freeing the backing >> device memory) >> 2. Return the folio back, split it back to single order folios > > Hi Balbir, > > Please refrain from using "split" here, since it confuses MM people. A folio > is split when it is still in use, but in this case, the folio has been freed > and needs to be restored to "free page" state. >
Yeah, the word split came from the initial version that called it folio_split_unref() and I was also thinking of the split callback for zone device folios, but I agree (re)initialization is a better term. >> >> The current code does not do 2. 1 followed by 2 does not work for >> Francois since the backing memory can get reused before we reach step 2. >> The proposed patch does 2 followed 1, but doing 2 means we've lost the >> folio order and thus the old order is passed in. Although, I wonder if the >> backing folio's zone_device_data can be used to encode any order information >> about the device side allocation. >> >> @Francois, I hope I did not miss anything in the explanation above. >> >>> I think someone from the graphics side really needs to take the lead on >>> understanding what the MM is doing (both currently and in the future). >>> I'm happy to work with you, but it feels like there's a lot of churn right >>> now because there's a lot of people working on this without understanding >>> the MM side of things (and conversely, I don't think (m)any people on the >>> MM side really understand what graphics cards are trying to accomplish). >>> >> >> I suspect you are referring to folio specialization and/or downsizing? >> >>> Who is that going to be? I'm happy to get on the phone with someone. >> >> Happy to work with you, but I am not the authority on graphics, I can speak >> to zone device folios. I suspect we'd need to speak to more than one person. >> > > -- > Best Regards, > Yan, Zi
