On Wed, Oct 28, 2026 at 11:12:47AM -0700, Kevin Loughlin wrote: > 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?
I'm not sure what is meant here. But if a lot of memory is free and it gets merged beyond MAX_PAGE_ORDER and then it's not reported, that's counterintuitive. > 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!
