Re: [PATCH RFC v2 00/18] mm/virtio: skip redundant zeroing of host-zeroed reported pages

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

On Mon, Apr 20, 2026 at 10:38:19PM -0400, Gregory Price wrote:
> On Mon, Apr 20, 2026 at 07:33:38PM -0400, Michael S. Tsirkin wrote:
> > On Mon, Apr 20, 2026 at 08:20:57PM +0200, David Hildenbrand (Arm) wrote:
> > > On 4/20/26 14:51, Michael S. Tsirkin wrote:
> > 
> > > > A lot of churn, and my concern is, if we miss even one
> > > > place, silent, subtle data corruption will result and only
> > > > on some arches (x86 will be fine).
> > > 
> > > Which would *already* be the case of you use folio_alloc(GFP_ZERO)
> > > instead of magical vma_alloc_folio() + folio_zero_user().
> > > 
> > > I don't really see how vma_alloc_folio_hints() -- that also consumes the
> > > address -- is any better in that regard?
> > 
> > By itself, it is not. But the issue is propagating the address from
> > there all over mm. If we miss even one place - we get a subtle cache
> > corruption on non x86.
> > 
> 
> Why does it need to propogate?
> 
> Can we leave folio_zero_user() callers the same, but add a PG_zeroed
> check in folio_zero_user() that skips the zeroing (but not the cache
> flush) and clear the PG_zeroed bit?
> 
> Is this feasible?

I do not see how - this would require leaking the page flag out of the
buddy allocator.


> You don't eliminate the folio_zero_user(), but maybe we shouldn't?
> 
> (a bit naive here - i haven't checked the PG_zeroed lifetime, i did
>  see it overloads PG_private - so this might not be feasible)
> 
> > 
> > I also note that we need a flag for free in order to implement
> > balloon deflate as you asked. Here, I reused the hints.
> > 
> 
> I'd sooner just implement this as
> 
>    ___put_folio(folio, gfp_t)
> 
>    __put_folio(folio) { ___put_folio(folio, NULL); }
> 
> And change the free path to take overloaded gfp flags.
> Some of the existing ones might even be useful as-is.
> 
> It's essentially the same thing, but prevents a bunch of churn and
> saves us a new concept.
> 
> optional gfp flags on free seem like genuinely useful interface for
> certain callers (definitely not all).
> 
> ~Gregory

But we do not have a gfp_t flag meaning "this has been zeroed"
and when I proposed something similar in v1, David hated abusing
gfp flags for what is not an allocation property.