From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-qt1-f178.google.com (mail-qt1-f178.google.com [209.85.160.178]) (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 C19A2451072 for ; Tue, 20 Jan 2026 18:18:53 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.160.178 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768933136; cv=none; b=Rwdau+DY0b7iPvcFweYde5xhtPdB3BPssmpbxN10fdk0AeFmAa5fvdG/gpBF9nE/CK7FyvcEjJv0JdwhBiTAAvhai4Q+7WBA5RVvPYWVixRVuS/rtvixMCOW7PrVKd4jnMF+nDhiztktwPZn5+xMXWV/KGVMXQlhuGbc/rG1eyI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768933136; c=relaxed/simple; bh=XEUWYxPei4NEkgDam7A7un1qS7q4dsbYFTPlbpjhsk4=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=qAIPTGgBRsJ+2wrOQ2+4TeTrtt0n9cAVslsSt6JAoxXIc42gz6kYEm5jO39pciEjlHTojcXJuBXxW+ghj7SfTA6xqe03Re+gCOptegB1jUokAVQNJKUIh6AnZ9o+iX2p0bvFqtoB3pgs7bAUQu7rfF3jqxhfNFafgZJsQa3nwdI= 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=QYPy29cg; arc=none smtp.client-ip=209.85.160.178 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="QYPy29cg" Received: by mail-qt1-f178.google.com with SMTP id d75a77b69052e-5029fb0b977so40412781cf.0 for ; Tue, 20 Jan 2026 10:18:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gourry.net; s=google; t=1768933132; x=1769537932; darn=vger.kernel.org; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc:subject:date:message-id:reply-to; bh=UtgC14b32AkerxxtW7iTRCLeOq1ZZH1b7K2qfFqW7v4=; b=QYPy29cgzGhNOhwVxsQB7qyLliEa8lwjDch/wP9i+quS0k/hiP4F/aLENpvpEqG0Jk /IevR3umxfRc1BmJS6+D81camWZv/b3yFy/6DAi3vEdhNlvyuv9RMyg3YK/8HvwDmFly ysKJ4uSrBmnAVcu5RyoFNZSoSNxFvSV3Ng1lvk8OVzENH6cCDto+3K/C6zQ0Y+0fSE/q mvBOEgzzQQqyBzeYcl2kDSm0HMoC5eI7F1Y1A677ICp5zmIhaXiAwdbKGyp9qpfuTaTa 4N2MTE1ezm4kmKm9dVmjP02NfPqw73DwC8r+UWQB49mKu+n8UTvNclf11GTEoKerflTt L2+w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768933132; x=1769537932; h=in-reply-to:content-transfer-encoding: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=UtgC14b32AkerxxtW7iTRCLeOq1ZZH1b7K2qfFqW7v4=; b=NlV1VM3o/NOAJW09pRwJ+8l0Txa22N8yxOc6x1SkzW5DNfZtc4QoS/QQ0V4c4kTXep fpbrUi1H/apyI/qVIF/xwbVxRVG11XNc3mSyK6EPN6L3Iphs5/OSqz3sjXjfg2I10tuh JAXLqUWi9sFLDLuDLrCoRjoZhfV3tHynS/V2znnoieXnGzkkJEkPDRoPAX64wq/BxZtQ raiH4mPOtTkxOwVvDb6LteZbm+fLK44k4JyTn9F+Ln3Z3uSFKbEELFNNAeZFyjBdIry6 ucwDcX6JWXv3BASAF+riFz+QhX70XywnEXBE1wuAc1fF7pFm63aP10B8eM9m+YDINJ/c Arjw== X-Forwarded-Encrypted: i=1; AJvYcCWsDEVXx1IHIyIBf+b2rhaVWB+LrfYeaJSof8tN+UK9WQ0ujypXqNbnXXPaxbIibANaSlVj80/MezhQ+l8=@vger.kernel.org X-Gm-Message-State: AOJu0Yw1/tvP7EjKh5uSlmnfKMoOBWhWXOgALz5aLPznWIJd2M9hdP6z TtzcYzWpBSSQn0+mcMfI4L34iMQguU5yzFTS57K8eyvbfcTSVudqFRg3hpZRkistqsw= X-Gm-Gg: AY/fxX5RbUhvqcCE6EdOqJZbHsRVGy9dmnE7hphg5EdLtRVe02PRFDKmS2uPIB2jKar VyddSQLpBzOzsTfASPX32iUC6OorPRlC0OexssvQE/n6P0HVFT5u7PYAsrg/z65mGpbkB4Pzdhh /5oJX6J3bU/rhioZfRxuMoW7pmFiRfAJ3jGzCZ5ETXZ72SUZu3U5w06Mfy97iUc8Ru28VDp0oic 3szu4vvSnnx5sb41cEkUBtDKfNgF3RgA9D18nhPpdwx3kmXKVhJj8xa6+hHXfY++MHZ/B4XBUQs JOMxVtc9FnHUNCxwwR+IjJnTR5N7HTd6zf3WCLrj7yfkdbcCvS2BPRz2V7C1iuQ8r1H0v3ZlJaM vA6trYjpq1syRlTbITuVGLY6CQT7uARSuAXxdem1h5nCiF+Dhel1aU97fyncE9/VvmpyOTiHZ9r /cxCf3C0Ik17m5ZDqJEm1hv3nNucQyVb8ZXuhTP5QDUYgs43dk2M3B8Tsfe9FWa3CwpcgkdOQqY TVzRDpy X-Received: by 2002:ac8:7d93:0:b0:501:459b:6138 with SMTP id d75a77b69052e-502a179c71emr233059251cf.65.1768933132218; Tue, 20 Jan 2026 10:18:52 -0800 (PST) Received: from gourry-fedora-PF4VCD3F (pool-96-255-20-138.washdc.ftas.verizon.net. [96.255.20.138]) by smtp.gmail.com with ESMTPSA id d75a77b69052e-502a1d6e67csm94446971cf.7.2026.01.20.10.18.51 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 20 Jan 2026 10:18:51 -0800 (PST) Date: Tue, 20 Jan 2026 13:18:19 -0500 From: Gregory Price To: Li Zhe Cc: david.laight.linux@gmail.com, akpm@linux-foundation.org, ankur.a.arora@oracle.com, dan.j.williams@intel.com, dave@stgolabs.net, david@kernel.org, fvdl@google.com, joao.m.martins@oracle.com, jonathan.cameron@huawei.com, linux-cxl@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, mhocko@suse.com, mjguzik@gmail.com, muchun.song@linux.dev, osalvador@suse.de, raghavendra.kt@amd.com, wangzhou1@hisilicon.com, zhanjie9@hisilicon.com Subject: Re: [PATCH v2 0/8] Introduce a huge-page pre-zeroing mechanism Message-ID: References: <20260120094744.5d92e34a@pumpkin> <20260120103949.7673-1-lizhe.67@bytedance.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=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20260120103949.7673-1-lizhe.67@bytedance.com> On Tue, Jan 20, 2026 at 06:39:48PM +0800, Li Zhe wrote: > On Tue, 20 Jan 2026 09:47:44 +0000, david.laight.linux@gmail.com wrote: > > > On Tue, 20 Jan 2026 14:27:06 +0800 > > "Li Zhe" wrote: > > > > > In light of the preceding discussion, we appear to have reached the > > > following understanding: > > > > > > (1) At present we prefer to mitigate slow application startup (e.g., > > > VM creation) by zeroing huge pages at the moment they are freed > > > (init_on_free). The principal benefit is that user space gains the > > > performance improvement without deploying any additional user space > > > daemon. > > > > Am I missing something? > > If userspace does: > > $ program_a; program_b > > and pages used by program_a are zeroed when it exits you get the delay > > for zeroing all the pages it used before program_b starts. > > OTOH if the zeroing is deferred program_b only needs to zero the pages > > it needs to start (and there may be some lurking). > > Under the init_on-free approach, improving the speed of zeroing may > indeed prove necessary. > > However, I believe we should first reach consensus on adopting > “init_on_free” as the solution to slow application startup before > turning to performance tuning. > His point was init_on_free may not actually reduce any delays on serial applications, and can actually introduce additional delays. Example ------- program_a: alloc_hugepages(10); exit(); program b: alloc_hugepages(5); exit(); /* Run programs in serial */ sh: program_a && program_b in zero_on_alloc(): program_a eats zero(10) cost on startup program_b eats zero(5) cost on startup Overall zero(15) cost to start program_b in zero_on_free() program_a eats zero(10) cost on startup program_a eats zero(10) cost on exit program_b eats zero(0) cost on startup Overall zero(20) cost to start program_b zero_on_free is worse by zero(5) ------- This is a trivial example, but it's unclear zero_on_free actually provides a benefit. You have to know ahead of time what the runtime behavior, pre-zeroed count, and allocation pattern (0->10->5->...) would be to determine whether there's an actual reduction in startup time. But just trivially, starting from the base case of no pages being zeroed, you're just injecting an additional zero(X) cost if program_a() consumes more hugepages than program_b(). Long way of saying the shift from alloc to free seems heuristic-y and you need stronger analysis / better data to show this change is actually beneficial in the general case. ~Gregory