Re: [PATCH RFC v2 17/18] mm: add free_frozen_pages_hint and put_page_hint APIs

["Michael S. Tsirkin" <mst@redhat.com>]

On Tue, Apr 21, 2026 at 03:30:53PM +0200, David Hildenbrand (Arm) wrote:
> On 4/21/26 15:16, Michael S. Tsirkin wrote:
> > On Tue, Apr 21, 2026 at 12:56:00PM +0200, David Hildenbrand (Arm) wrote:
> >> On 4/20/26 14:51, Michael S. Tsirkin wrote:
> >>> Add free_frozen_pages_hint(page, order, hints) to free a page
> >>> while marking it as pre-zeroed when PGHINT_ZEROED is set.
> >>> The PG_zeroed flag is set after __free_pages_prepare so it
> >>> survives on the free list.
> >>>
> >>> Add __folio_put_hint(), folio_put_hint(), and put_page_hint()
> >>> wrappers for the put_page path.
> >>
> >> Can we defer that change?
> > 
> > We can - it's a dependency of the balloon deflate, which you asked
> > me to implement. I'm more interested in reporting, myself.
> 
> Just to be clear, I said:
> 
> "I'd assume ordinary inflating+deflating of the balloon would also end
> up with pre-zeroed pages. We'd just need a (mm/balloon.c -specific)
> interface to tell the buddy that the pages are zeroed."
>
> So while I think there will be value in that in the futur once we
> figure out a clean interface, I don't recall asking you to implement that?


Right. you also said:

	Not blocking, but I don't want something that is too coupled to
	free-page reporting optimizations in the buddy. The comment above
	MAGIC_PAGE_ZEROED triggered my reaction.

so I interpreted this as meaning "it's nice to have (not blocking), but
you either need to implement this to demonstrate that indeed, it is not
too coupled, or prove in some other way that it is not too coupled".


> 
> -- 
> Cheers,
> 
> David