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