On Wed, Oct 28, 2026 at 2:01 AM David Hildenbrand (Arm) <[email protected]> wrote: > > On 10/27/26 03:56, Kevin Loughlin wrote: > > > [...] > > > mm/page_alloc.c | 248 ++++++++++++----- > > This diff stat should give you a good indication why this series is not > acceptable.
Got it. I will keep that in mind going forward, especially if I end up attempting a v2 that simplifies things. On that note, I believe the majority of the bloat in mm/page_alloc.c comes from... 1. supporting the legacy inflate/deflate option 2. introducing support for various page sizes to be unaccepted (1) I can get rid of by dropping the inflate/deflate option, which I think makes sense given free page reporting should be sufficient to enable dynamic guest downsizing in cooperative scenarios. (2) becomes simpler in part just by doing (1). For further simplification, we could potentially restrict free page reporting for CoCo guests to the current 4 MB MAX_PAGE_ORDER instead of supporting any order 2 MB and up. There's a trade-off here for reporting effectiveness under fragmentation, but perhaps support for 4 MB only (and its relative simplicity) could be acceptable? Especially since we would then maintain the invariant that all pages on the unaccepted list are MAX_PAGE_ORDER? If I can sufficiently simplify the changes (especially in mm/), do you potentially see a path forward purely for the free page reporting aspect of this (dropping inflate/deflate)? Thank you for taking the time to review, David!
