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 20C0E39526B for ; Mon, 13 Apr 2026 21:37:54 +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=1776116276; cv=none; b=ODxPrKnuKjWFL6TYoSE2I8ISNxav92E95n3l1IiKZNvoeN3LWUzFHxkHhkYPfEGInUXjNOMestF1U5QdawcR4EfnB4dTEHJX64tUGhzpPcqsdiS4JYOhtd4GFRhpC0xraM86+7mFU+aUGwwh6GVWvFcao0bm04uzBDq4Z35Z9vM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776116276; c=relaxed/simple; bh=+REFOP9fZuODX/fES3ySGttDUJLG0sFlGek/PVIurD8=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=stgS25u2ZTa+QnZH4qF/87l0BjJoWwMmYW4MLfrvY34fAMRfJCvk6YdiwnVqLWAlYFj4ZYZrUl9nZW4H66Cs+HlZ/zo7h7GUspPT6PhTbB97+yjeeSz52iBJTcdjpAJgSiBs4V/RD6ypiquqlPLDmllxy+mQQyUk2fjnrMSCNSE= 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=QYQIMOmb; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b=LgynDOpa; 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="QYQIMOmb"; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b="LgynDOpa" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1776116274; 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=zypwX4nPzqqGkby3h4xchNBDXe75SXkmhVGTD+QMyg0=; b=QYQIMOmbGIONz09ochtiFBcekra6VkZnFRHq40QLVeFc/JSBH7zcg/hdvOpV5LaBBEd8Sl dnxpxB3viGIgMarVJM0flY1QDBYY1CpK20EXhqA7eds3INpr/ZfFOoeRDLOWM1hUGiqx9W B5lbDH67IvLtIcGPiwUwczbsRGJ2qVw= Received: from mail-wr1-f72.google.com (mail-wr1-f72.google.com [209.85.221.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-300-K9Zvz9QTNWCNbevXTZ9vnQ-1; Mon, 13 Apr 2026 17:37:52 -0400 X-MC-Unique: K9Zvz9QTNWCNbevXTZ9vnQ-1 X-Mimecast-MFC-AGG-ID: K9Zvz9QTNWCNbevXTZ9vnQ_1776116271 Received: by mail-wr1-f72.google.com with SMTP id ffacd0b85a97d-43d00dd913cso5313574f8f.1 for ; Mon, 13 Apr 2026 14:37:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=google; t=1776116271; x=1776721071; 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=zypwX4nPzqqGkby3h4xchNBDXe75SXkmhVGTD+QMyg0=; b=LgynDOpaqs0xTWRUONz2Qu1CF77/RNaWMpkqhuvnUH/z+5eSsT0bR75oQJwfc44IoQ enwzi46C2YPEVCb58LKuML5aCRD4FpoA71Jtp9bZEClqu+M9epRcAuOw/NFLED6C7pMK lLuuYuRn014ASa3jw4OdoND9Am5itCYjOw7vFDTjSrJi+o3zYeeL7WCQ23e+IXTbH9GN OpOf04g3bealC5JP9J9ja7WBpm9nnoC/sgxVLBejY3wHaJaHoeD9EMm6Ei5tEJMmTQhr seU2zI+EzvfvFwTVKh+4L1cUUjgXA2Uu6vatE9mXH0coImyhdS/LaaDj+aS0vEfxUZNn o0yg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1776116271; x=1776721071; 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=zypwX4nPzqqGkby3h4xchNBDXe75SXkmhVGTD+QMyg0=; b=sHV4BFRUWnBisvEIK77JQPRPv/bm5Vg3GK91zT/aqv3IK4fg+3uzfJyeUbtfRR9VlG oQ1mLE0+2Wyilo4QqP3Cb5Qq5kANArZ6PW3Omo2J6wvQlipkzECwMbP1weaXFJLQSuYn AHKbs4VEMaLbWY2cSGZqgNq7GcYOoId9navW11KPzvIb8rMJItXdN+jI1oFOtCkw1C2j xXlou5lry0XH+kKxrU+W6ghok4uMUjVVHxi3cO+Ywsw+rcBBGyAdFHstTgVwCuk/zotI DuJiWQBQDGUV4YT0E0b+YQEESXJOLiaZ5QoI9zpKUgu6pk2VbqXcbrHIB6fce3ZqR/gS mNPw== X-Gm-Message-State: AOJu0Yz0L88RFDhYtcN3swV7s/nZMKC2NOkkigbafcj0Pi9RSparoT5o fbwo77os/g50qB8XD673A0m+0/+lhXaKkxhJLUp62JTU5G3zGeGcWKgShb8IVMEc3h1XHMD5cvg i/1XlFjCrgF1+eywQP832oU1GZ2YoorBt3/a6rkLi+F78QileSawulk6jnA6kQqajUw== X-Gm-Gg: AeBDiev4G3ZMK4pQqaTN5oIXlXQfQ9N6HEgQDElN9w08NzlROR4q4QsF5a+AkN8tPQc hHufWpdW9oFzrrMMMLRczTev2W4C9m7fJMXLVZepyBzPQGJlMjbakZUx5X0VV3xPgDvnrUWeuSV te7TE2di6H+TT5FMO5DxPIOOi8famam1xJLQ8sHdgD58nFfDGG0ORG2SHCiVMTomgvpQqhB313c 8YZ+bfYSBsANcXUy91U6wIz6ywIHI7GiElOdXnaaHcxNrkCXCpscLiGT7tTLrNNgLpR1bOQ7vz2 sPTY3ML4HznkCVXau5KQnOeYMe7t0X4Qo3tqV3E10CFhTn1HdFzAs0EgPPjqt5RECkk4tMKSLPP zpvSdVYi5Tbpzg3LuaTwcutHIdb7/xoXXTfdxW7bh61M= X-Received: by 2002:a05:6000:2dc1:b0:43d:7a97:78b7 with SMTP id ffacd0b85a97d-43d7a977b07mr6473094f8f.50.1776116270816; Mon, 13 Apr 2026 14:37:50 -0700 (PDT) X-Received: by 2002:a05:6000:2dc1:b0:43d:7a97:78b7 with SMTP id ffacd0b85a97d-43d7a977b07mr6473061f8f.50.1776116270231; Mon, 13 Apr 2026 14:37:50 -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 ffacd0b85a97d-43d7cf533b7sm6776966f8f.18.2026.04.13.14.37.48 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 13 Apr 2026 14:37:49 -0700 (PDT) Date: Mon, 13 Apr 2026 17:37:46 -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 3/9] mm: add __GFP_PREZEROED flag and folio_test_clear_prezeroed() Message-ID: <20260413172139-mutt-send-email-mst@kernel.org> 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: On Mon, Apr 13, 2026 at 11:05:40AM +0200, David Hildenbrand (Arm) wrote: > 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. I suspect PG_dropbehind (or any flag, e.g. PG_owner_priv_1 that the patch that I sent uses) won't work as-is for this. The issue is PAGE_FLAGS_CHECK_AT_PREP: #define PAGE_FLAGS_CHECK_AT_PREP \ ((PAGEFLAGS_MASK & ~__PG_HWPOISON) | ...) This includes all page flags except hwpoison. check_new_pages() verifies that none of these flags are set on an allocated page. PG_dropbehind is part of PAGEFLAGS_MASK, so if we set it in page_del_and_expand() to mark a page as pre-zeroed, check_new_pages() would reject it as a bad page. I guess we could exclude it unconditionally, but this looks like a riskier change to me. No? > > (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. It's all rather messy, from what I saw so far there are arch specific hacks actually around this. > -- > Cheers, > > David