From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id D21EE3A4F47 for ; Mon, 13 Apr 2026 08:10:52 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.133.124 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776067854; cv=none; b=F1A2mAvmPy/9LskKs6cJD9NRfgOO0tULV7owF0W6TOJWPgKzf2MLrK2xSH6QHWYXzar/pTzuGJLWttKuCWkji4PdidJlE0mdgiPVEXnP93iQyrn3byauD/pqoOEcSWCQVXVsXcruPW9V3f3y4TGvMUNrRpE1BFtXArzYLNd1qn0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776067854; c=relaxed/simple; bh=GEunZ9UcB09fSEmuMjlxeLs2Xmd5ksXd1isCdjy3oSk=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=UcYzP2AU/8M+3ba66xJYFFTzVCNN1ZZkkbOQOVRrNjQHXebLBcnUfUzadunmX72wqqtlPsn2fGEv1P97IMGLde2xenvHC3zk8ZfABP0L2r5+wzxRPqtS+OeMQni8Q2XZrqCAj2KUgWGtLgPaE4gBjQkO2yWrvv9+4zr483CBDag= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=QimhEpKY; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b=XcL0j5yE; arc=none smtp.client-ip=170.10.133.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="QimhEpKY"; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b="XcL0j5yE" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1776067851; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=OaQMCi5HMfp/OHds/BFFbF3BJqhYWZNHL69rqmLc+L4=; b=QimhEpKYn4IQUcwcnHLjdMxc9iTfIcbxXrwfvg16zuLp0nRbmj+wiEKWmxr790JZGCzwJC gjKzZH9duU/JCZQAC+ydepL6UYLCcjEvJ//DCKYYmlsGDsGyekdwNHlPaVjfc9w+zEYzQ2 Bfko8lXqpk1c8FnF4ofSY35Y5aGcFLE= Received: from mail-wm1-f69.google.com (mail-wm1-f69.google.com [209.85.128.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-604-iyniMqImMzi7RxXiNLDoeQ-1; Mon, 13 Apr 2026 04:10:50 -0400 X-MC-Unique: iyniMqImMzi7RxXiNLDoeQ-1 X-Mimecast-MFC-AGG-ID: iyniMqImMzi7RxXiNLDoeQ_1776067848 Received: by mail-wm1-f69.google.com with SMTP id 5b1f17b1804b1-488dcaf2f2fso11012525e9.0 for ; Mon, 13 Apr 2026 01:10:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=google; t=1776067848; x=1776672648; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=OaQMCi5HMfp/OHds/BFFbF3BJqhYWZNHL69rqmLc+L4=; b=XcL0j5yEYPKHS47gZ+PGaCaqFNajWbBNOUSa0W4gMnzB2Ga+ATi3EzYuSBgQMK5eN7 i5Dz6hP7El90OUsQ/+eYHPobrJ7Xourcyc6U6XtHJKjydxCKx3Y2Cd/5lFNyjtYUvxvg xYv5xtNeArPLR1w18Y74t9C99yX/Id/LcsguN1dFwG5GZ1SsplxCnIcH45RoduLeXZs3 h+XN0Ssn7CrNWh3VBPUGy7AE29+hTCI2UnucXLuBTOZ6idxIXkaAtF6S+oEAhVEL+CsE hMZ09gIybrkH4DX1vrrnT3tzUSquKTt8DR4ClDEPXAQunA6ILZpKEAhuamjG5bCIFfoy WZtQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1776067848; x=1776672648; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=OaQMCi5HMfp/OHds/BFFbF3BJqhYWZNHL69rqmLc+L4=; b=B+gXAk288yQcHrzjpeU9RsJn8Va1hg/tFI/3MzEOlSU7qUfLNAhw6qy2QknrGljoxx T9jKR+kSA/Wh4bKw1gvoyGjY9cuEnKzMEBwxiunCNEmr5nVpthQZU/70Rotm+7W2erlG zFuEfzLpLwHmyrAQ8TrYHlLXPsnI+gQgW3S3VSTwZ+gTpevh9KwN31NmaiKbNH8K4d8E VGLnWL+bz265x4vwVlkaniso8+2jmkRzrbwA9vDsuILVHZkIJeR+LPXs0lUj27oRtqz0 YJF8bMMuyNvkAXW4C3syJDfufy0PQYiRaR7pHMVjptNtxZh+cPzm8r+hxY6RPcmBDQCU 9iQQ== X-Gm-Message-State: AOJu0YyJ65BdLFhTRT5gAZaf93s9CmqRCmdpIMG3LxgGzW8OIdn+EWlW J5zgnQfhYr7eMbJdL4wtiEzqqP6rX6cw28sOumSNRM8e1gI96I0sL7h7hLO12FILswj3T4zjl0p l6W6sv4Nyqtmp+Du6YMAqIrwaATTOmgBdLuzVHNymFxr7OZdILRORpKivjZNtTlTC7g== X-Gm-Gg: AeBDieuHZjygiOonb3hLooWsD4lojgYXh96xuKkbSyc8K/PK1pOMriPdNTtuBnQ0KnC hFmVn5jan8XQdNPSQ1vnTXgWYbQoESWiq5KWjGKjspzW0QBZfawYINZgd8QkbNQWtqaP9ukXwxp KPhRuFoslNrIx6WM/qgGU0yGEzo5W3924RqUOYCxuynbFtLf7BNjP9tmWOHWCu3f1Q8MkcU/MLe n136QFu+P9rHA3/2TaazGC+aJa4XxoY6iimTHgReELIQost+u8Ho9guJEv5rkZRR21vzGIg3pIP jxnx0t+ditFO71ZMk3ep3qFRhHp+xQXOV4BGE9kMJnJeAbFoQIQ5raZg97fsCWChUMUhXmCsyu0 7F38Y43RTFKfwqFLEaMC4BaKnm9M9tLjJ50dA0EohHR4= X-Received: by 2002:a05:600c:4715:b0:488:9e54:94c0 with SMTP id 5b1f17b1804b1-488d67e7dd4mr183038805e9.8.1776067848262; Mon, 13 Apr 2026 01:10:48 -0700 (PDT) X-Received: by 2002:a05:600c:4715:b0:488:9e54:94c0 with SMTP id 5b1f17b1804b1-488d67e7dd4mr183038325e9.8.1776067847773; Mon, 13 Apr 2026 01:10:47 -0700 (PDT) Received: from redhat.com (IGLD-80-230-25-21.inter.net.il. [80.230.25.21]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-488d5344e28sm297869325e9.7.2026.04.13.01.10.45 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 13 Apr 2026 01:10:47 -0700 (PDT) Date: Mon, 13 Apr 2026 04:10:43 -0400 From: "Michael S. Tsirkin" To: "David Hildenbrand (Arm)" Cc: linux-kernel@vger.kernel.org, Andrew Morton , Vlastimil Babka , Brendan Jackman , Michal Hocko , Suren Baghdasaryan , Jason Wang , Andrea Arcangeli , linux-mm@kvack.org, virtualization@lists.linux.dev, Lorenzo Stoakes , "Liam R. Howlett" , Mike Rapoport , Johannes Weiner , Zi Yan Subject: Re: [PATCH RFC 2/9] mm: page_reporting: skip redundant zeroing of host-zeroed reported pages Message-ID: <20260413040143-mutt-send-email-mst@kernel.org> References: <2155527a-e077-4b71-80ee-d735f9984f60@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2155527a-e077-4b71-80ee-d735f9984f60@kernel.org> On Mon, Apr 13, 2026 at 10:00:58AM +0200, David Hildenbrand (Arm) wrote: > On 4/13/26 00:50, Michael S. Tsirkin wrote: > > When a guest reports free pages to the hypervisor via the page reporting > > framework (used by virtio-balloon and hv_balloon), the host typically > > zeros those pages when reclaiming their backing memory. However, when > > those pages are later allocated in the guest, post_alloc_hook() > > unconditionally zeros them again if __GFP_ZERO is set. This > > double-zeroing is wasteful, especially for large pages. > > > > Avoid redundant zeroing by propagating the "host already zeroed this" > > information through the allocation path: > > > > 1. Add a host_zeroes_pages flag to page_reporting_dev_info, allowing > > drivers to declare that their host zeros reported pages on reclaim. > > A static key (page_reporting_host_zeroes) gates the fast path. > > > > 2. In page_del_and_expand(), when the page was reported and the > > static key is enabled, stash a sentinel value (MAGIC_PAGE_ZEROED) > > in page->private. > > > > 3. In post_alloc_hook(), check page->private for the sentinel. If > > present and zeroing was requested (but not tag zeroing), skip > > kernel_init_pages(). > > > > In particular, __GFP_ZERO is used by the x86 arch override of > > vma_alloc_zeroed_movable_folio. > > > > No driver sets host_zeroes_pages yet; a follow-up patch to > > virtio_balloon is needed to opt in. > > > > Signed-off-by: Michael S. Tsirkin > > Assisted-by: Claude:claude-opus-4-6 > > --- > > include/linux/mm.h | 6 ++++++ > > include/linux/page_reporting.h | 3 +++ > > mm/page_alloc.c | 21 +++++++++++++++++++++ > > mm/page_reporting.c | 9 +++++++++ > > mm/page_reporting.h | 2 ++ > > 5 files changed, 41 insertions(+) > > > > diff --git a/include/linux/mm.h b/include/linux/mm.h > > index 5be3d8a8f806..59fc77c4c90e 100644 > > --- a/include/linux/mm.h > > +++ b/include/linux/mm.h > > @@ -4814,6 +4814,12 @@ static inline bool user_alloc_needs_zeroing(void) > > &init_on_alloc); > > } > > > > +/* > > + * Sentinel stored in page->private to indicate the page was pre-zeroed > > + * by the hypervisor (via free page reporting). > > + */ > > +#define MAGIC_PAGE_ZEROED 0x5A45524FU /* ZERO */ > > Why are we not using another page flag that is yet unused for buddy pages? Because we need to report the status *after* it left buddy. And all flags are in use at that point. > Using page->private for that, and exposing it to buddy users with the > __GFP_PREZEROED flag (I hope we can avoid that) does not sound > particularly elegant. But propagating this all over mm does not sound too palatable, right? There's precedent with MAGIC_HWPOISON already. Better ideas? Thanks! > Also, if we're going to remember that some pages in the buddy are > pre-zeroed, it should better not be free-page-reporting specific. > 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. > Indeed, it's also easily possible - it's a separate optimization, though. Another simple enhancement is including hugetlbfs freelists in page reporting. Doesn't need to block this patchset though, right? > > -- > Cheers, > > David