From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-qk1-f179.google.com (mail-qk1-f179.google.com [209.85.222.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id A1B913F23AA for ; Thu, 14 May 2026 14:07:52 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.222.179 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778767675; cv=none; b=mxoohJ2cFC5yA6UFuRMzlzDFiJDteqD9izd8cyYE11DXsYf/yxWN+VDS8yOdS7yXv9TNAaaqb8IPs+uelKJcElUw3/ux2xobbEZclafSd1X2UN6DAAEer9yuK9GjNWig0GpkSGsQ0WBHE0/FBQkDEt+ucVRCDNfm3+3Ev4bfspY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778767675; c=relaxed/simple; bh=gxxWJB/qB/J8fJqa5y8sKRNuXpYzfb0WmIuH/Ebl/eQ=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=PvXB0Kb3ZSTeTx1CH5/Bbennr5K3TIRBS6pCNEWjqutwiucoVOSawULd+epBU4uf0fI2nEWqbCXiA6kKrs82dZcQZ7A3wM+qgvaaBB3jvvv1eVqrlAUQeoich2lJH5Zhx4Y7cDM/zNBXPHlGjJtaQd3q/SBqgrQ3U/V3ZSSFxMw= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=gourry.net; spf=pass smtp.mailfrom=gourry.net; dkim=pass (2048-bit key) header.d=gourry.net header.i=@gourry.net header.b=YYzvyLc6; arc=none smtp.client-ip=209.85.222.179 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=gourry.net Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gourry.net Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gourry.net header.i=@gourry.net header.b="YYzvyLc6" Received: by mail-qk1-f179.google.com with SMTP id af79cd13be357-90b2fcf90a0so562863485a.1 for ; Thu, 14 May 2026 07:07:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gourry.net; s=google; t=1778767671; x=1779372471; 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=uzkmFh1ZQqsmfN+ZQzPcPofqB0NQiVM+nge3NejXpRM=; b=YYzvyLc6Nzu/B6A0UKex+oG/R2M/6R1Jhqk0VG93/4EJCmyAGJffJgfrontUJC9XBz E38lJa+oOqi41X0e7gY55XkaF5HV7ccqGiRoyVpc3HXhVrTikE3X9aNNWjonZqt4KNiq W0U38lsSfJ6ySQ2WGEI0wmjP5nRiBcJrpglFBdI/WFdUWnzcjL13vpm5oQp3E5xVEcAx +KstXAFqnT7eITq40VWhA1aelrpsgyFX6MpHb1WjTjmZfjXg0jgJSzyNsRrIC36xhyBW mXts+Vjld6BdB85YrzVx+w1QkBKhHC5tlZmmBzbd5JZEfuwoFCI0c49D+l3qOa9rMvgH WJfg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1778767671; x=1779372471; 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=uzkmFh1ZQqsmfN+ZQzPcPofqB0NQiVM+nge3NejXpRM=; b=qZHJm8vkwXajaWsLAUg9yxQT/VMiLXYnOcquNhco1emVl8aib/Cu+zysuzYJ6DuJbw V2sKPeWQI0ThwiP+Ii7T5DtWTDpqbvIgnCelCOp8tBxpbP30D/uA6nK5XDtEp6M3wRgh vpVOf6cTkqP274kJ9X3lABPCNp48Olh+tO5LeNHEBdnMja6N01kn7HNlh0WhkuuOAIXw vETkR5Re/TgVQ7sUKaCEFmQqDQP2bVnKbGtchXoXU9Rb5uyX+tUVk0Byhk5wHr4cP/1F nyG1nsO/i/OLs+i0gbXgZlvdOjzUVGaUacFk5tt0xUVZRje4u+Ul8I+w4I8LaJfIGpsk qV3w== X-Gm-Message-State: AOJu0YxV+MZHJDRfIMx7uI0DdBoe8tbYLvbkVCnAPS+JZJKts4YSPw3/ oTz3nzUN4c2xnQSb/v01iFqSBtBsb11YV0PBImhSv5QqAytaq7BoN4VO4AuRfW9iQIc= X-Gm-Gg: Acq92OF+8vLoO2v5DcxdpPd6a4+d6CvVztpVeGp0Hl3+2Orz8Z4XXWDVeVOQm6IAmtK LWXa3eETziJ/9pmvJuAdI6Ckr6vmnlUaOr301ds16oTUUlEgt3jZY6iM87ZcaRcmqcWH4UAbdeH EmLrFQIH1KiEikeETISjC4+h3hst288y/ckwPW5b3R8t8rUVKvIamStmHC33JKrBHpa/3KF+7+E IH/9MOaSumRASN+973F/W6gQltHmFLRvUpjmWl1EFArF25xrwLBhNwIrtcm3qUc/U/RRsZmUMxE y1tEDJJlRdFvhlBx/2buDe7nWQNp045a/1yfmcqNsU0oXIczMkZJYJXoQVfsX7aCQJudNgB15// SsCRv1k9BrWygjaA7FJ6x34wLbUVPkYvbGsz2FWBmR9/a+HRdkZMpKGKobEFY/uqublmhtXUbrt TgjbikO2JQb3ffYY7N7/BAkgfDyj+6dSo/xS6zs3qGBm1PqBW59e5MDXqhnxEC4/VlW93qpOBmV P41OCr4M/+1 X-Received: by 2002:a05:620a:4809:b0:8ee:b817:9a03 with SMTP id af79cd13be357-910af5599c8mr528786685a.9.1778767671219; Thu, 14 May 2026 07:07:51 -0700 (PDT) Received: from gourry-fedora-PF4VCD3F (pool-100-36-248-188.washdc.fios.verizon.net. [100.36.248.188]) by smtp.gmail.com with ESMTPSA id af79cd13be357-910bae27359sm271238485a.17.2026.05.14.07.07.49 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 14 May 2026 07:07:50 -0700 (PDT) Date: Thu, 14 May 2026 10:07:48 -0400 From: Gregory Price To: "Michael S. Tsirkin" Cc: linux-kernel@vger.kernel.org, "David Hildenbrand (Arm)" , Jason Wang , Xuan Zhuo , Eugenio =?iso-8859-1?Q?P=E9rez?= , 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 , 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: Re: [PATCH v7 18/31] mm: memfd: skip zeroing for zeroed hugetlb pool pages Message-ID: References: <0ec51a9091b5ed3f61a49935953dd537d6c87428.1778616612.git.mst@redhat.com> 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: <0ec51a9091b5ed3f61a49935953dd537d6c87428.1778616612.git.mst@redhat.com> On Tue, May 12, 2026 at 05:06:43PM -0400, Michael S. Tsirkin wrote: > gather_surplus_pages() pre-allocates hugetlb pages into the pool > during mmap. Pass __GFP_ZERO so these pages are zeroed by the > buddy allocator, and HPG_zeroed is set by alloc_surplus_hugetlb_folio. > > Add bool *zeroed output to alloc_hugetlb_folio_reserve() so > callers can check whether the pool page is known-zero. memfd's > memfd_alloc_folio() uses this to skip the explicit folio_zero_user() > when the page is already zero. > > This avoids redundant zeroing for memfd hugetlb pages that were > pre-allocated into the pool and never mapped to userspace. > > Signed-off-by: Michael S. Tsirkin > Assisted-by: Claude:claude-opus-4-6 > --- > include/linux/hugetlb.h | 6 ++++-- > mm/hugetlb.c | 11 +++++++++-- > mm/memfd.c | 14 ++++++++------ > 3 files changed, 21 insertions(+), 10 deletions(-) > ... snip ... > @@ -2221,6 +2221,12 @@ struct folio *alloc_hugetlb_folio_reserve(struct hstate *h, int preferred_nid, > h->resv_huge_pages--; > > spin_unlock_irq(&hugetlb_lock); > + > + if (zeroed && folio) { > + *zeroed = folio_test_hugetlb_zeroed(folio); > + folio_clear_hugetlb_zeroed(folio); > + } > + > return folio; > } Hmmm... if the intent is to simply communicate to the next function up whether the folio has been zeroed just so that function can zero it - does it make sense instead to just zero it in this function instead? Also the only user is memfd, and that appears to always want the folio zeroed, so i think it simplifies this entire patch to: struct folio* alloc_hugetlb_folio_reserve() { ... if (folio && !folio_test_hugetlb_zeroed(folio)) folio_zero_user(folio, 0); else if (folio) folio_clear_hugetlb_zeroed(folio); return folio; ... } with no API changes ~Gregory