From: "David Hildenbrand (Arm)" <david@kernel.org>
To: "Michael S. Tsirkin" <mst@redhat.com>, linux-kernel@vger.kernel.org
Cc: 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,
Lorenzo Stoakes <lorenzo.stoakes@oracle.com>,
"Liam R. Howlett" <Liam.Howlett@oracle.com>,
Mike Rapoport <rppt@kernel.org>,
Johannes Weiner <hannes@cmpxchg.org>, Zi Yan <ziy@nvidia.com>
Subject: Re: [PATCH RFC 3/9] mm: add __GFP_PREZEROED flag and folio_test_clear_prezeroed()
Date: Mon, 13 Apr 2026 11:05:40 +0200 [thread overview]
Message-ID: <b258160c-5287-43dd-b56e-268c403b85ea@kernel.org> (raw)
In-Reply-To: <b21b0ba353330f24b9e10ee5bf01b60f32043327.1776033771.git.mst@redhat.com>
On 4/13/26 00:50, Michael S. Tsirkin wrote:
> The previous patch skips zeroing in post_alloc_hook() when
> __GFP_ZERO is used. However, several page allocation paths
> zero pages via folio_zero_user() or clear_user_highpage() after
> allocation, not via __GFP_ZERO.
>
> Add __GFP_PREZEROED gfp flag that tells post_alloc_hook() to
> preserve the MAGIC_PAGE_ZEROED sentinel in page->private so the
> caller can detect pre-zeroed pages and skip its own zeroing.
> Add folio_test_clear_prezeroed() helper to check and clear
> the sentinel.
I really don't like __GFP_PREZEROED, and wonder how we can avoid it.
What you want is, allocate a folio (well, actually a page that becomes
a folio) and know whether zeroing for that folio (once we establish it
from a page) is still required.
Or you just allocate a folio, specify GFP_ZERO, and let the folio
allocation code deal with that.
I think we have two options:
(1) Use an indication that can be sticky for callers that do not care.
Assuming we would use a page flag that is only ever used on folios, all
we'd have to do is make sure that we clear the flag once we convert
the to a folio.
For example, PG_dropbehind is only ever set on folios in the pagecache.
Paths that allocate folios would have to clear the flag. For non-hugetlb
folios that happens through page_rmappable_folio().
I'm not super-happy about that, but it would be doable.
(2) Use a dedicated allocation interface for user pages in the buddy.
I hate the whole user_alloc_needs_zeroing()+folio_zero_user() handling.
It shouldn't exist. We should just be passing GFP_ZERO and let the buddy handle
all that.
For example, vma_alloc_folio() already gets passed the address in.
Pass the address from vma_alloc_folio_noprof()->folio_alloc_noprof(), and let
folio_alloc_noprof() use a buddy interface that can handle it.
Imagine if we had a alloc_user_pages_noprof() that consumes an address. It could just
do what folio_zero_user() does, and only if really required.
The whole user_alloc_needs_zeroing() could go away and you could just handle the
pre-zeroed optimization internally.
--
Cheers,
David
next prev parent reply other threads:[~2026-04-13 9:05 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-12 22:50 [PATCH RFC 0/9] mm/virtio: skip redundant zeroing of host-zeroed reported pages Michael S. Tsirkin
2026-04-12 22:50 ` [PATCH RFC 1/9] mm: page_alloc: propagate PageReported flag across buddy splits Michael S. Tsirkin
2026-04-13 19:11 ` David Hildenbrand (Arm)
2026-04-13 20:32 ` Michael S. Tsirkin
2026-04-14 9:08 ` David Hildenbrand (Arm)
2026-04-12 22:50 ` [PATCH RFC 2/9] mm: page_reporting: skip redundant zeroing of host-zeroed reported pages Michael S. Tsirkin
2026-04-13 8:00 ` David Hildenbrand (Arm)
2026-04-13 8:10 ` Michael S. Tsirkin
2026-04-13 8:15 ` David Hildenbrand (Arm)
2026-04-13 8:29 ` Michael S. Tsirkin
2026-04-13 20:35 ` Michael S. Tsirkin
2026-04-14 9:18 ` David Hildenbrand (Arm)
2026-04-14 10:22 ` Michael S. Tsirkin
2026-04-14 15:32 ` David Hildenbrand (Arm)
2026-04-14 15:36 ` Michael S. Tsirkin
2026-04-12 22:50 ` [PATCH RFC 3/9] mm: add __GFP_PREZEROED flag and folio_test_clear_prezeroed() Michael S. Tsirkin
2026-04-13 9:05 ` David Hildenbrand (Arm) [this message]
2026-04-13 20:37 ` Michael S. Tsirkin
2026-04-14 9:04 ` David Hildenbrand (Arm)
2026-04-14 10:29 ` Michael S. Tsirkin
2026-04-14 15:46 ` David Hildenbrand (Arm)
2026-04-16 8:45 ` Michael S. Tsirkin
2026-04-13 21:37 ` Michael S. Tsirkin
2026-04-13 22:06 ` Michael S. Tsirkin
2026-04-13 23:43 ` Michael S. Tsirkin
2026-04-14 9:06 ` David Hildenbrand (Arm)
2026-04-12 22:50 ` [PATCH RFC 4/9] mm: skip zeroing in vma_alloc_zeroed_movable_folio for pre-zeroed pages Michael S. Tsirkin
2026-04-12 22:50 ` [PATCH RFC 5/9] mm: skip zeroing in alloc_anon_folio " Michael S. Tsirkin
2026-04-12 22:50 ` [PATCH RFC 6/9] mm: skip zeroing in vma_alloc_anon_folio_pmd " Michael S. Tsirkin
2026-04-12 22:51 ` [PATCH RFC 7/9] mm: hugetlb: skip zeroing of pre-zeroed hugetlb pages Michael S. Tsirkin
2026-04-12 22:51 ` [PATCH RFC 8/9] mm: page_reporting: add flush parameter to trigger immediate reporting Michael S. Tsirkin
2026-04-12 22:51 ` [PATCH RFC 9/9] virtio_balloon: a hack to enable host-zeroed page optimization Michael S. Tsirkin
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=b258160c-5287-43dd-b56e-268c403b85ea@kernel.org \
--to=david@kernel.org \
--cc=Liam.Howlett@oracle.com \
--cc=aarcange@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=hannes@cmpxchg.org \
--cc=jackmanb@google.com \
--cc=jasowang@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=lorenzo.stoakes@oracle.com \
--cc=mhocko@suse.com \
--cc=mst@redhat.com \
--cc=rppt@kernel.org \
--cc=surenb@google.com \
--cc=vbabka@kernel.org \
--cc=virtualization@lists.linux.dev \
--cc=ziy@nvidia.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.