From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-qt1-f180.google.com (mail-qt1-f180.google.com [209.85.160.180]) (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 6BE914418CD for ; Tue, 20 Jan 2026 18:38:41 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.160.180 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768934323; cv=none; b=iDGI4pOpMw7nQlSfeezJGbeE72clq4k5TlwZKUptsfkpyyMtY2Cvs3n/z6tmhFsCZO+EAFfr390F0c06q6ZRAbx9fS0X9b6Z+NrwEvjtiRJtNyjTQljMZXn3fY+L/I65HQg/zG828Bk+4FTkRrI4iFvONl2a4lA1zjSaH9Qhb8I= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768934323; c=relaxed/simple; bh=YmhekH3BtLWUqg6+5Ty3aH1uKKxcFx123EWvmahHQL0=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=QtC409wOpl59umw/bdyERKxUsyfqGbLxOyEbTgLfrtWtvl9MgP3ntrlTIhpLiFdFkDB8fLLQFrJ+1xXwbwp4beOiJwPNirMSAyCEdP57OjPAd6lG6fmWKZ8fBekS6TSzZG8GyK6cAWNNILnpiPCu0DldMBcbjAJU4k7YvJz0r+0= 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=jCp42yeE; arc=none smtp.client-ip=209.85.160.180 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="jCp42yeE" Received: by mail-qt1-f180.google.com with SMTP id d75a77b69052e-501488a12cbso59034791cf.3 for ; Tue, 20 Jan 2026 10:38:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gourry.net; s=google; t=1768934320; x=1769539120; 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=iOV934DYRc9ERWmoCuXpOFxaUel0buwbS4A/jVjuySc=; b=jCp42yeE+qfiGMUfLqVlxCb/4aF1LniQxlCgbIBs/+HG9prS8N8Z+kIj0TGK2BJVAh eEd7EyCT3SFfo8Ku1HrUzcDrfdIRq7oRUi8XYM+9CpsrOEaOwn5Of7It5rhFZ8dHaFZ7 dvS59pmFwMCMBKOsX5pS2OVAYB0JEltjJWHTZ9uZ7Mko7SCauveD1/H8LWHa2UW0V3QL u/mMehgWeG2KuBhyv7LXdO/v5t3WzBGO4uLRE84zIjwuojYTUyLKCh1SuvPt5m0JRrJA Zwjge3uO++RJblexiBQPlbIzVxvzmO67VGPhL8QpaZ/Tj1VOr/3EOQeRdh1/kVfORknv LMpA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768934320; x=1769539120; 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=iOV934DYRc9ERWmoCuXpOFxaUel0buwbS4A/jVjuySc=; b=KX2Ig8YX9mpLBYkaqDV+5XQhmmh/n9uXTOdDvHtQ6GgfBw2VQhmz5cmX2ibNJq0Rid 5MB7CTyaZwxZSI5RYlrZfbNzFJu6EQUi2LeZkZC2s6g/zBVEhUm4wpoNCWyxKN3OqS5+ aRMloMzLMzgnm6urPUD5A+gS184RiAd1HrJK7k5T2jLXrmkvMLdJOeVVAfAc+m91sMtC tqrokf75qNsGVNDc/WwfquEX8kwGfPpR7Z+udMYVx8C9EKK2JjS8Ir7PW4RnZrPbbJQa 378acg1UgJgbh7g9vJJvJmWsFk76v/JgeB/tppamvBjzF3ZgP/Rs5Y/yN1t1WmaL0ir5 yVAw== X-Forwarded-Encrypted: i=1; AJvYcCUKtUz+nuFHZ1khrRmgWq4WEAgl1pZbvj9hUtVh5WqkGHu1Yu3UVTxGOeY13cHvmTZ9a9akuYVdcBJlN5Y=@vger.kernel.org X-Gm-Message-State: AOJu0Yw1McjB4J7PvLbfKnxKH7I2kDHUODTskD180/mmEc/zVb9rrH6X EqA+9pGdthXDzlCM2C5c7v5H+d1ImAEqNkl2Ypv7v4BSxLSLM1nDatnUSg4OnYDRPiY= X-Gm-Gg: AY/fxX5+gy91tBVMFD1oXx7ukB5hwgtQPkzx0Cl2kvrB66dzHsEvJ1qczXMTghUFZL2 Q74dq5IXn25cWmlRUPauBQc2rTureAB+T0CDM7yyFisFgzmSWBp9SkYMh9/fKJ6kA6N0mEh7+Wg tRCMG562G3A64b45pBXDgMfGuVtzIhGuReugnwkCVReNcsKLUQI0uO7mIvlp8qccLUdqfCyy1FM /C0sRBWPdlPYZcVJuewBYE04g9i6BNhrPmnPB6M91EgOq7ditxyP7QGWPmwR7qEp7wfPjz7f/1m mRLK2ShXybLpbfbILEMCGoviNAT9j6sspBlzarx1aZ97wWvgmlL9wY7jz9V/e6Oq5FVlbPji+Bf 9lVppnmKuVi+i3f+xZEwv/KWSxmetKp7/IA+4cKXdTnAkTy2mVH1eMNCKh1X2OZm3cCrp5bzb3W yu/CQQTWspvyoWtPv7i4bAne81OzS+w5Jzuyu08rbzdHYDuFyl+5EiijbFXtamSmWl9Ltjug== X-Received: by 2002:ac8:7dc2:0:b0:502:9c4f:e284 with SMTP id d75a77b69052e-502d84dee8fmr37431281cf.30.1768934320230; Tue, 20 Jan 2026 10:38:40 -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-502a1d9f296sm105269001cf.12.2026.01.20.10.38.39 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 20 Jan 2026 10:38:39 -0800 (PST) Date: Tue, 20 Jan 2026 13:38:07 -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=us-ascii Content-Disposition: inline In-Reply-To: On Tue, Jan 20, 2026 at 01:18:19PM -0500, Gregory Price wrote: > 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. > As an addendum to this: Maybe this is an indication that a global switch (per-node sysfs entry) is not the best decision, and that maybe there's a better way to accomplish this with a reduced scope. hugetlb-only sysfs knob - same issue as current proposal, but better placed why would you only apply this on one node? prctl thingy - limits effects to just those opting into alloc-on-free - probably still needs hugetlb-internal zeroed-pages tracking but doesn't require the rest of the machinery do it entirely in userland - modify the software to zero before exit - use MAP_UNINITIALIZED - useful and simple if your hugetlb use case is homogenous there's probably more oprtions ~Gregory