From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sg-1-104.ptr.blmpb.com (sg-1-104.ptr.blmpb.com [118.26.132.104]) (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 C36DC36C5A4 for ; Tue, 20 Jan 2026 06:27:39 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=118.26.132.104 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768890464; cv=none; b=ZYT86Tdw/B3OVBHlKPF1EAsk5FvT8VSm9OnMA397p6pVYdYg1pPs2XtNAtN3fX0lOHHz+At22bKQ6eFEKImX4xKmwlkw+1+kZHfhTlC/27cFD2O25roVzySFnd05K3p1zFIbs3uMBZQxi4uoIhs/o/LkRQgZSPBtYu5EokV/BNc= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768890464; c=relaxed/simple; bh=D1TQMPSXv5PjTxr6RBKljUmzcShoTJ2wcS+IGRnPiEo=; h=From:Date:Message-Id:Mime-Version:To:Cc:Subject:In-Reply-To: References:Content-Type; b=hm74JubD694d+r9z+NNGPBKbjh+501snb2QhhHhv5OAwYIeEXZIQ7JISq28e8zP2yDZDVGQZb+TOlSdeW5Amtn7lI0SHQvJdfP0qWjFRp98XdsUZ9ZtZghzcljCsRI5RdCpK30X4iurURxBsTu4RbGAssHDWPam+8Lk027nwoJc= 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=CH2la0no; arc=none smtp.client-ip=118.26.132.104 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="CH2la0no" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; s=2212171451; d=bytedance.com; t=1768890448; h=from:subject: mime-version:from:date:message-id:subject:to:cc:reply-to:content-type: mime-version:in-reply-to:message-id; bh=D1TQMPSXv5PjTxr6RBKljUmzcShoTJ2wcS+IGRnPiEo=; b=CH2la0noBDTfmNxG1mvb65RbwKCp2kcAoyUGrNBcRMGP5unjqoJp3Z4MI8Rh6tLNPXiDJD HRfqwtc9IW4GNVkZXGC4pdEANZAbV9jVKburZ8o/Kt9hoO8ZGcJWDRgTes0MdhoVC2DJ34 MaV0D8+GDs8hgtF6jmanDNt0WTGXUVEkE5ongYYTcFDEjK29t9uT9/XnO221pVD88hOfMC UrDShaPzVyv5paKgf7vEdjIEl6e8E8d7oASD057HsxV914OSpZiBzcgLkDJTl6FODSX2+h FIdRAa2Xhi4TLf824nAr1OGdJyCXCZw/iPyQfYW53q/RU91eA608F3Lnjmh1jw== From: "Li Zhe" Date: Tue, 20 Jan 2026 14:27:06 +0800 Message-Id: <20260120062706.91078-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 X-Lms-Return-Path: To: Cc: , , , , , , , , , , , , , , , , , , Subject: Re: [PATCH v2 0/8] Introduce a huge-page pre-zeroing mechanism Content-Transfer-Encoding: 7bit In-Reply-To: <87wm1ih5kb.fsf@oracle.com> References: <87wm1ih5kb.fsf@oracle.com> X-Mailer: git-send-email 2.45.2 X-Original-From: Li Zhe Content-Type: text/plain; charset=UTF-8 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. (2) Deferring the zeroing from allocation to release may occasionally cause the thread that frees the page to differ from the one that originally allocates it, so the clearing cost is not charged to the allocating thread. Because this situation is rare and the existing init_on_free mechanism in the kernel already exhibits the same behavior, we deem the consequence acceptable. (3) The function __unmap_hugepage_range() employs the MMU-gather mechanism, which refrains from dropping the page reference while holding the PTL (spinlock). This allows huge-page zeroing to be performed in a non-atomic context. (4) Given that, in the vast majority of cases, the same thread that allocates a huge page also frees it, and the exceptions highlighted by David are genuinely rare[1]. We can achieve faster application startup by implementing an init_on_free-style mechanism. (5) Going forward we can further optimize the zeroing process by leveraging a DMA engine. If the foregoing is accurate, I propose we add a new hugetlbfs mount option to achieve the init-on-free behavior. Thanks, Zhe [1]: https://lore.kernel.org/all/83798495-915b-4a5d-9638-f5b3de913b71@kernel.org/#t