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 5CA933BB670 for ; Mon, 8 Jun 2026 08:39:15 +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=1780907960; cv=none; b=aSVj+roUmbf3tdtq8hP3PWeLam5qbdodXL8MqbgXQsBT3STH1CCRl0FnGu1tgW7i2Li9NWZ7vCBxOjqDVFY8oPU3YGrj3+wNTIp+GXxjGxA9CmwiJACNMjOC7TjKa99/k2JfdNZrOfkwLauUg9hhvZ2fXFCIS3b+8u6B55TSrBo= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780907960; c=relaxed/simple; bh=GCycL8yBIVDI7qw2NQ3Ow74lnO1SdliLzn2m5qQWypg=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=lXWEWLhpWt4eV/ec5oasdnIf6J0qu0IVkKPN4RsDwaBI79U/IdiDcqkuBRghitbBcjaNoqT6vsKPXe2Gbru/k/S9nfDmgMGgNgU2Yk7N+PEHi0roTYk3xBQ9FAed4OR+moJ+EEm9CR1WfOtl/k5Mc/RqKVtzdu0awxG6Ctob4qA= 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=Oc+QV+qs; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b=nzEQA5ti; 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="Oc+QV+qs"; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b="nzEQA5ti" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1780907954; 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=3+rjGl0pefUb9vVc/tCmuC8Z28GLOAKmmZQW2TUwDlo=; b=Oc+QV+qs9O3xfqQQflJcbNRabWfHjVlloaRFnzN3mCCW+M31WbwmvhXSWjtIknERJDhox4 N9tcvjXj0Uxs9VwL+poSFf45qk4+TPpwfqRz5Bigcu0sunhE49j5ETt9qlO3FY9oAAdM2t UJdQK0lJXAGBYK5UAWRjwhVEcWa0pvo= Received: from mail-wr1-f69.google.com (mail-wr1-f69.google.com [209.85.221.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-396-46nWSEFYNvulAwSad06P1g-1; Mon, 08 Jun 2026 04:39:12 -0400 X-MC-Unique: 46nWSEFYNvulAwSad06P1g-1 X-Mimecast-MFC-AGG-ID: 46nWSEFYNvulAwSad06P1g_1780907951 Received: by mail-wr1-f69.google.com with SMTP id ffacd0b85a97d-45efa12a788so2885226f8f.2 for ; Mon, 08 Jun 2026 01:39:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=google; t=1780907951; x=1781512751; 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=3+rjGl0pefUb9vVc/tCmuC8Z28GLOAKmmZQW2TUwDlo=; b=nzEQA5tiICNOagPm2zFLXj+kRP7aiQdgXoIpkOHtc5NMHIeHk/AL1i27YM9eMwfVLS pgP8dgVviuFvDwroo+cvlQov0a+8tvpzJbRe1Rb9ZvaklbN2SGWGBPF0sZNPCKCA8Bx+ QNDKL3Sx2Okw961S+wBLoUEkowBU9CanI0pM+HI8akpFud/AJQ4cnJe3rz93rhE7vuzB 2WPbo2B1Vs09qw6pl9ZlipNi0QmdGuzvvUdxC9NtXbGbZJRowVCiG1Jr3fLCj0YUXkRQ duj913qFHiHjH1TuaNO6CG5d2cOHGXeJMYZaou1OfosQgOuDc/H4LdnLZ19PTj+pZpem wXUQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1780907951; x=1781512751; 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=3+rjGl0pefUb9vVc/tCmuC8Z28GLOAKmmZQW2TUwDlo=; b=JXxQ3KjRpruXZfx9QI1ePqEK4VXCxRbB96ELMwoMfF86Lf1umd1iD6RbGy9lWC05In kBKRPs6sdNryKJS5XfqiIOJG8oSGVTuqb8fpSgrIHdiXHdCpZTQMzjx66B0+vrIq/Byq zp4wpSzcufl64gped5KXorETHwwQsytakR2AF6/5DmxgdcYDZ2MaNYtzsYGV1YBMTsd6 e1wRxPJKdHg25A+T3K68qLdQp1dZgeX6baOMeFuNHVp3UMofH6TQp+NxNn4w6f+A8jSO +G3QVzsaa2fTLDZgYi/WIZD3BAwFBlpjSbte2X1uAeWToedPu3FtxU07bu0iBnJNnh0X Msxw== X-Gm-Message-State: AOJu0YyjKBx02+9GHn4xp+7Hi5klDDeRg0XB/zVqaGC5ios53pNWtIX/ P5nHbaBucSWAhypkVFwsew8MvvrX1Xfyz22pYBhT4Jn1c0/ozk03Z4gCTaybUFA2SnM4a8C3MFW kBv57ShYZL09sDwnhf2UPJn+l4PfJUREFhokbHiQwMg6lMAJ3/faOPEs9vBCnWFFxsHbve+laCt iep0Hz26mqkRlMxrbEiXQiIa3KpyRZxXyCf9ThSA/oQ3U= X-Gm-Gg: Acq92OH9xoUQPLqV6umJxd0KQsrtwR6ba3mKAvidB6ODLUiW9Gd76O1Zmo2/K+4S8CZ xIurWs2jPdtM5a/EJgHAM0c6I3VvWtfChXw6tFmQg7MSCDDPDBf5LOtH4cMPK9ntCj1tREwibPV 3XYCLPSwIPxutdWVunYTrdb8YCadCAErgMJRCHKK2V487M62W2DZI5yvYH83aJDwNfQKdwmGswc SJdUs5MwKuOcFSUsV0Dk75y5D3CXzwbBJQ8LXPGxJqcJZ1N1vPq6V56cFdO7MqTUs7zN960bujx SlgIh/PM6cibAOEaqIDQiu0IU4ep/Z4pJeQXFWxeCH2bB6NI3utWFyFHrn1Foy/nMaiXUiq9QD4 sPuaky+vXaIw9mzIyMFmK584= X-Received: by 2002:a5d:4a85:0:b0:45f:f142:d55a with SMTP id ffacd0b85a97d-460302e5e92mr18158194f8f.14.1780907950778; Mon, 08 Jun 2026 01:39:10 -0700 (PDT) X-Received: by 2002:a5d:4a85:0:b0:45f:f142:d55a with SMTP id ffacd0b85a97d-460302e5e92mr18158101f8f.14.1780907950019; Mon, 08 Jun 2026 01:39:10 -0700 (PDT) Received: from redhat.com ([31.152.37.159]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-4601f2f67c6sm48744304f8f.16.2026.06.08.01.39.03 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 08 Jun 2026 01:39:09 -0700 (PDT) Date: Mon, 8 Jun 2026 04:39:02 -0400 From: "Michael S. Tsirkin" To: linux-kernel@vger.kernel.org Cc: "David Hildenbrand (Arm)" , Jason Wang , Xuan Zhuo , Eugenio =?utf-8?B?UMOpcmV6?= , Muchun Song , Oscar Salvador , Andrew Morton , Lorenzo Stoakes , "Liam R. Howlett" , Vlastimil Babka , Mike Rapoport , Suren Baghdasaryan , Michal Hocko , Brendan Jackman , Johannes Weiner , Zi Yan , Baolin Wang , Nico Pache , Ryan Roberts , Dev Jain , Barry Song , Lance Yang , Hugh Dickins , Matthew Brost , Joshua Hahn , Rakie Kim , Byungchul Park , Gregory Price , Ying Huang , Alistair Popple , Christoph Lameter , David Rientjes , Roman Gushchin , Harry Yoo , Axel Rasmussen , Yuanchu Xie , Wei Xu , Chris Li , Kairui Song , Kemeng Shi , Nhat Pham , Baoquan He , virtualization@lists.linux.dev, linux-mm@kvack.org, Andrea Arcangeli Subject: [PATCH v10 25/37] mm: use __GFP_ZERO in alloc_anon_folio Message-ID: <13ed2aa6607d510bd8dc6d602e96626511ee4fee.1780906288.git.mst@redhat.com> References: 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: X-Mailer: git-send-email 2.51.2.2891.g4157995a80.dirty X-Mutt-Fcc: =sent Convert alloc_anon_folio() to pass __GFP_ZERO instead of zeroing at the callsite. post_alloc_hook uses the fault address passed through vma_alloc_folio for cache-friendly zeroing. Note: before this series, replacing clear_user_highpage() with __GFP_ZERO was unsafe on cache-aliasing architectures because __GFP_ZERO uses clear_page() without a dcache flush. With this series, it is safe if the caller passes a valid user address (not USER_ADDR_NONE) to vma_alloc_folio() etc., which delivers it to post_alloc_hook() for the dcache flush via folio_zero_user(). It is only unsafe if USER_ADDR_NONE is passed. Note: with __GFP_ZERO, the folio is zeroed before mem_cgroup_charge(). If the charge fails, the zeroing work is wasted. Previously zeroing was done after a successful charge. This is inherent to moving zeroing into the allocator. Charge failures are rare (only at cgroup limits). Use folio_put_zeroed() on charge failure so the zeroed hint propagates to the buddy allocator, avoiding redundant re-zeroing on the next allocation attempt. Signed-off-by: Michael S. Tsirkin Reviewed-by: Gregory Price Assisted-by: Claude:claude-opus-4-6 --- mm/memory.c | 13 ++----------- 1 file changed, 2 insertions(+), 11 deletions(-) diff --git a/mm/memory.c b/mm/memory.c index 6c14b90f558e..6d6a3e1a02c1 100644 --- a/mm/memory.c +++ b/mm/memory.c @@ -5265,25 +5265,16 @@ static struct folio *alloc_anon_folio(struct vm_fault *vmf) goto fallback; /* Try allocating the highest of the remaining orders. */ - gfp = vma_thp_gfp_mask(vma); + gfp = vma_thp_gfp_mask(vma) | __GFP_ZERO; while (orders) { folio = vma_alloc_folio(gfp, order, vma, vmf->address); if (folio) { if (mem_cgroup_charge(folio, vma->vm_mm, gfp)) { count_mthp_stat(order, MTHP_STAT_ANON_FAULT_FALLBACK_CHARGE); - folio_put(folio); + folio_put_zeroed(folio); goto next; } folio_throttle_swaprate(folio, gfp); - /* - * When a folio is not zeroed during allocation - * (__GFP_ZERO not used) or user folios require special - * handling, folio_zero_user() is used to make sure - * that the page corresponding to the faulting address - * will be hot in the cache after zeroing. - */ - if (user_alloc_needs_zeroing()) - folio_zero_user(folio, vmf->address); return folio; } next: -- MST