From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sg-1-107.ptr.blmpb.com (sg-1-107.ptr.blmpb.com [118.26.132.107]) (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 0F3EA357A3B for ; Thu, 15 Jan 2026 09:37:09 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=118.26.132.107 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768469833; cv=none; b=U1zXuWg75owwdMhmaPHT+NlSzcA66UIFUHDDqqr5aw2V+VpCEJmMuo5mky09QCv1AEtD1o2jKiRjoa+9+Vi5o26le9JcXBki4suMe9s7EosRuF5E1bfXP555CepvPXZ/MZiX5gKG3wJYdharuXU5xAHCcFsG4eN4QIKIMeTMQtQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768469833; c=relaxed/simple; bh=XVoCcRcwukbWPmxE9/fFSzcJWK5S7s4Wodf2nB8Kikk=; h=Subject:In-Reply-To:References:Cc:From:Mime-Version:To:Date: Message-Id:Content-Type; b=kaX/RaZxbHE8gvsPo10sRxiw/BUAZSNkmwE89Hu7JE1CnYEjHJvjWUjpXnHzG91EvB4J1UqCOi0OM4EoeXsXtcTfQGKqZ4qJarRIGToxP9u0Q+h2tgYQT70je8q2oZmEE74FgLJUpNr6SlPRV0ErK/LoOjM6/1nzm2uGxo9/y8o= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=bytedance.com; spf=pass smtp.mailfrom=bytedance.com; dkim=pass (2048-bit key) header.d=bytedance.com header.i=@bytedance.com header.b=ld4zvJrM; arc=none smtp.client-ip=118.26.132.107 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=bytedance.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=bytedance.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=bytedance.com header.i=@bytedance.com header.b="ld4zvJrM" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; s=2212171451; d=bytedance.com; t=1768469818; h=from:subject: mime-version:from:date:message-id:subject:to:cc:reply-to:content-type: mime-version:in-reply-to:message-id; bh=fk2RJ3eO3k5qQ8Xkg0gzN5tmD8UXjDhhHfjptuDS4jI=; b=ld4zvJrMjLJtXzTom3TIhTkjQd7jcCWIcFEXAysIX4bkry1kq3/7xm+p4pwiHc2zEoHfZP Yy1Nh6DAn8sFYYs7xeM0r0HXtwKvuFa78WazZ8DX6FefVwQl/yvpvs/cotrgNkuoBrIaP6 eKumNkYbQWkGPVpoWEWwmDDFo4ml5JIbvgkK3jpPazl+Oc6A3sRrZX9+gvYrgGBTMRm6DK 9lP5HXg6lXX0EUDdK/2NHuZUzVZCV2nu2/LS5qHr4XLj+DZ+FzIhGsiHcI3xNL570tiYce u+6C4YMdGtvchBN4Al1j2a7PxPaHvGJD9Mr2Ho3v8jLsV4jr87xsY2aaEwlVtQ== Subject: Re: [PATCH v2 0/8] Introduce a huge-page pre-zeroing mechanism In-Reply-To: <9daa39e6-9653-45cc-8c00-abf5f3bae974@kernel.org> References: <9daa39e6-9653-45cc-8c00-abf5f3bae974@kernel.org> Content-Transfer-Encoding: 7bit Cc: , , , , , , , , , , , From: "Li Zhe" Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 X-Lms-Return-Path: To: Date: Thu, 15 Jan 2026 17:36:41 +0800 Message-Id: <20260115093641.44404-1-lizhe.67@bytedance.com> X-Original-From: Li Zhe X-Mailer: git-send-email 2.45.2 Content-Type: text/plain; charset=UTF-8 On Wed, 14 Jan 2026 18:21:08 +0100, david@kernel.org wrote: > >> But again, I think the main motivation here is "increase application > >> startup", not optimize that the zeroing happens at specific points in > >> time during system operation (e.g., when idle etc). > >> > > > > Framing this as "increase application startup" and merely shifting the > > overhead to shutdown seems like gaming the problem statement to me. > > The real problem is total real time spent on it while pages are > > needed. > > > > Support for background zeroing can give you more usable pages provided > > it has the cpu + ram to do it. If it does not, you are in the worst > > case in the same spot as with zeroing on free. > > > > Let's take a look at some examples. > > > > Say there are no free huge pages and you kill a vm + start a new one. > > On top of that all CPUs are pegged as is. In this case total time is > > the same for "zero on free" as it is for background zeroing. > > Right. If the pages get freed to immediately get allocated again, it > doesn't really matter who does the freeing. There might be some details, > of course. > > > > > Say the system is freshly booted and you start up a vm. There are no > > pre-zeroed pages available so it suffers at start time no matter what. > > However, with some support for background zeroing, the machinery could > > respond to demand and do it in parallel in some capacity, shortening > > the real time needed. > > Just like for init_on_free, I would start with zeroing these pages > during boot. > > init_on_free assures that all pages in the buddy were zeroed out. Which > greatly simplifies the implementation, because there is no need to track > what was initialized and what was not. > > It's a good question if initialization during that should be done in > parallel, possibly asynchronously during boot. Reminds me a bit of > deferred page initialization during boot. But that is rather an > extension that could be added somewhat transparently on top later. > > If ever required we could dynamically enable this setting for a running > system. Whoever would enable it (flips the magic toggle) would zero out > all hugetlb pages that are already in the hugetlb allocator as free, but > not initialized yet. > > But again, these are extensions on top of the basic design of having all > free hugetlb folios be zeroed. > > > > > Say a little bit of real time passes and you start another vm. With > > merely zeroing on free there are still no pre-zeroed pages available > > so it again suffers the overhead. With background zeroing some of the > > that memory would be already sorted out, speeding up said startup. > > The moment they end up in the hugetlb allocator as free folios they > would have to get initialized. > > Now, I am sure there are downsides to this approach (how to speedup > process exit by parallelizing zeroing, if ever required)? But it sounds > like being a bit ... simpler without user space changes required. In > theory :) I strongly agree that init_on_free strategy effectively eliminates the latency incurred during VM creation. However, it appears to introduce two new issues. First, the process that later allocates a page may not be the one that freed it, raising the question of which process should bear the cost of zeroing. Second, put_page() is executed atomically, making it inappropriate to invoke clear_page() within that context; off-loading the zeroing to a workqueue merely reopens the same accounting problem. Do you have any recommendations regarding these issues? Thanks, Zhe