From: "Michael S. Tsirkin" <mst@redhat.com>
To: "David Hildenbrand (Arm)" <david@kernel.org>
Cc: linux-kernel@vger.kernel.org,
Andrew Morton <akpm@linux-foundation.org>,
Vlastimil Babka <vbabka@kernel.org>,
Brendan Jackman <jackmanb@google.com>,
Michal Hocko <mhocko@suse.com>,
Suren Baghdasaryan <surenb@google.com>,
Jason Wang <jasowang@redhat.com>,
Andrea Arcangeli <aarcange@redhat.com>,
linux-mm@kvack.org, virtualization@lists.linux.dev
Subject: Re: [PATCH RFC v2 00/18] mm/virtio: skip redundant zeroing of host-zeroed reported pages
Date: Mon, 20 Apr 2026 19:33:38 -0400 [thread overview]
Message-ID: <20260420192037-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <c199e47d-b2fd-42f3-9e50-c47c848dc72f@kernel.org>
On Mon, Apr 20, 2026 at 08:20:57PM +0200, David Hildenbrand (Arm) wrote:
> On 4/20/26 14:51, Michael S. Tsirkin wrote:
> >
>
> Hi!
>
> >
> > v2 - this is an attempt to address David Hildenbrand's comments:
> > overloading GFP and using page->private, support for
> > balloon deflate.
> >
> > I hope this one is acceptable, API wise.
> >
> > I also went ahead and implemented an alternative approach
> > that David suggested:
> > using GFP_ZERO to zero userspace pages.
> > The issue is simple: on some architectures, one has to know the
> > userspace fault address in order to flush the cache.
> >
> > So, I had to propagate the fault address everywhere.
>
> As I said, that might not be necessary. vma_alloc_folio() is the
> interface we mostly care about in that regard.
>
I'm not sure I follow what "might not be necessary". We need a fault
address so zeroing can be effective wrt cache. Since you asked that it's
done deep in post alloc hook, the address has to propagate all over mm.
> > 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.
hints are exactly that - if we forget to set them, all that happens
is that we do an extra zeroing. That is all.
> When we just do the right thing with vma_alloc_folio(GFP_ZERO), at least
> vma_alloc_folio() users will not accidentally do the wrong thing by
> forgetting to use folio_zero_user().
Well, it's simply that
1. if you plain forget folio_zero_user you get non zero on all arches
2. we *already* have folio_zero_user in place
> >
> > Still, you can view that approach here:
> > https://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost.git gfp_zero
> >
> > David, if you still feel I should switch to that approach,
> > let me know. Personally, I'd rather keep that as a separate
> > project from this optimization.
> I'd prefer if we extend vma_alloc_folio() to just handle GFP_ZERO for us.
Pls take a look at that tree then. What do you think of that approach?
Better? If you want it in form of patches, I can post them
in private or on list.
Let me know, I don't have a problem with that approach - I tested
it and the performance is the same. But the issue is that there's lot
of paths that have to propagate the fault address. It took me a while to
even find them all (assuming I found them all).
I also note that we need a flag for free in order to implement
balloon deflate as you asked. Here, I reused the hints.
> But let's hear other opinions first.
>
> --
> Cheers,
>
> David
next prev parent reply other threads:[~2026-04-20 23:33 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-20 12:51 [PATCH RFC v2 00/18] mm/virtio: skip redundant zeroing of host-zeroed reported pages Michael S. Tsirkin
2026-04-20 12:50 ` [PATCH RFC v2 01/18] mm: page_alloc: propagate PageReported flag across buddy splits Michael S. Tsirkin
2026-04-20 12:50 ` [PATCH RFC v2 02/18] mm: add pghint_t type and vma_alloc_folio_hints API Michael S. Tsirkin
2026-04-21 0:58 ` Huang, Ying
2026-04-20 12:50 ` [PATCH RFC v2 03/18] mm: add PG_zeroed page flag for known-zero pages Michael S. Tsirkin
2026-04-20 12:50 ` [PATCH RFC v2 04/18] mm: page_alloc: track PG_zeroed across buddy merges Michael S. Tsirkin
2026-04-20 12:50 ` [PATCH RFC v2 05/18] mm: page_alloc: preserve PG_zeroed in try_to_claim_block Michael S. Tsirkin
2026-04-20 12:50 ` [PATCH RFC v2 06/18] mm: page_alloc: thread pghint_t through get_page_from_freelist Michael S. Tsirkin
2026-04-20 12:50 ` [PATCH RFC v2 07/18] mm: post_alloc_hook: use PG_zeroed to skip zeroing, return pghint_t Michael S. Tsirkin
2026-04-20 12:50 ` [PATCH RFC v2 08/18] mm: hugetlb: thread pghint_t through buddy allocation chain Michael S. Tsirkin
2026-04-20 12:50 ` [PATCH RFC v2 09/18] mm: hugetlb: use PG_zeroed for pool pages, skip redundant zeroing Michael S. Tsirkin
2026-04-20 12:50 ` [PATCH RFC v2 10/18] mm: page_reporting: support host-zeroed reported pages Michael S. Tsirkin
2026-04-20 12:50 ` [PATCH RFC v2 11/18] mm: skip zeroing in vma_alloc_zeroed_movable_folio for pre-zeroed pages Michael S. Tsirkin
2026-04-20 12:50 ` [PATCH RFC v2 12/18] mm: skip zeroing in alloc_anon_folio " Michael S. Tsirkin
2026-04-20 12:50 ` [PATCH RFC v2 13/18] mm: skip zeroing in vma_alloc_anon_folio_pmd " Michael S. Tsirkin
2026-04-20 12:50 ` [PATCH RFC v2 14/18] mm: memfd: skip zeroing for pre-zeroed hugetlb pages Michael S. Tsirkin
2026-04-20 12:51 ` [PATCH RFC v2 15/18] virtio_balloon: add host_zeroes_pages module parameter Michael S. Tsirkin
2026-04-20 12:51 ` [PATCH RFC v2 16/18] mm: page_reporting: add flush parameter with page budget Michael S. Tsirkin
2026-04-20 12:51 ` [PATCH RFC v2 17/18] mm: add free_frozen_pages_hint and put_page_hint APIs Michael S. Tsirkin
2026-04-20 12:51 ` [PATCH RFC v2 18/18] virtio_balloon: mark deflated pages as pre-zeroed Michael S. Tsirkin
2026-04-20 18:09 ` [syzbot ci] Re: mm/virtio: skip redundant zeroing of host-zeroed reported pages syzbot ci
2026-04-20 18:20 ` [PATCH RFC v2 00/18] " David Hildenbrand (Arm)
2026-04-20 23:33 ` Michael S. Tsirkin [this message]
2026-04-21 2:38 ` Gregory Price
2026-04-21 2:21 ` Gregory Price
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260420192037-mutt-send-email-mst@kernel.org \
--to=mst@redhat.com \
--cc=aarcange@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=david@kernel.org \
--cc=jackmanb@google.com \
--cc=jasowang@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@suse.com \
--cc=surenb@google.com \
--cc=vbabka@kernel.org \
--cc=virtualization@lists.linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox