From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sg-1-100.ptr.blmpb.com (sg-1-100.ptr.blmpb.com [118.26.132.100]) (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 1FACB30F54C for ; Mon, 29 Dec 2025 12:29:30 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=118.26.132.100 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767011374; cv=none; b=mI2I4zwK/P9QcpxvbsWnP7JrRPFX8xVFWGwrfRO6m+5A0V3dTZh1yUqhgtoAVvqZh9nclAm07y4y99TdlPmfLaO33VY8b5aLL5dl9M4uzMtRoCMS2YLF9aMmAiUcrDu6IBVMMrITnpnJI6oD9FZyq4rHuJDlnSJimZ5AHqyBSYg= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767011374; c=relaxed/simple; bh=DyL/G9kKBvpgLEzvxHMBFeQFxclVz+zkzEXVUpDOVas=; h=To:Mime-Version:From:Message-Id:References:Cc:Subject:Date: In-Reply-To:Content-Type; b=koZE/7UJqr4Di+aq1zSgQZ4CZGX7caUFWKvPir+34w/jiaLQtGKvmekZwrg0JBlvSybHnv4sYRzTFqKSFOaRJHdCBCXPPI35/ytgk0RQHqgdlronoXnaFPZyqhFkkQe0Y6nLSzYYGXXxTx1aNFswC+LeTyNV6goCifA0QSv1NYE= 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=M01uOyU4; arc=none smtp.client-ip=118.26.132.100 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="M01uOyU4" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; s=2212171451; d=bytedance.com; t=1767011359; h=from:subject: mime-version:from:date:message-id:subject:to:cc:reply-to:content-type: mime-version:in-reply-to:message-id; bh=DyL/G9kKBvpgLEzvxHMBFeQFxclVz+zkzEXVUpDOVas=; b=M01uOyU4rGX+GDBWGhU/OG2fBHwrGLqzzCXgUIgaKcQz7eqQhGZF3WUXVTCVG5kAaoBo5i qck0IkBFwmpOuKjHl58HrUw59sZ7YbbwgmPbudrgX1RB8Aea+AOGuakaTtt4yqbpeSvnK6 SlBXftn0EXLRGOAOUTN0itvIpHlxoyqriohmC0UjsZJo/qi9N904PMPLbb4PA4SrQcnHrN ohb5rHtgQC8Kt7K2gxMO8e+ly6WF3/zScEXszrbPZehXhMNMhr6UGc3AqbNYOeG0FyMmzP 33iXBwNEStIWbJioDfb0mGKWLLjNna5AhH03xLyFwprAgNxqdE7I9UeAvZphmA== To: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 X-Original-From: Li Zhe From: "Li Zhe" X-Mailer: git-send-email 2.45.2 Message-Id: <20251229122856.7397-1-lizhe.67@bytedance.com> X-Lms-Return-Path: References: Cc: , , , , , , Subject: Re: [PATCH 0/8] Introduce a huge-page pre-zeroing mechanism Date: Mon, 29 Dec 2025 20:28:56 +0800 In-Reply-To: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=UTF-8 On Fri, 26 Dec 2025 13:42:13 -0800, fvdl@google.com wrote: > Is there any situation where you would write anything else than 'max' > to the new sysfs file? E.g. in which scenarios does it make sense to > *not* pre-zero all freed hugetlb folios? There doesn't seem to be a > point to just doing a certain number. You can't know for sure if the > number you read will remain correct, as it's just a snapshot. So how > would you determine a correct number other than 'max'? My view is that each application knows its own huge-page requirement and should therefore write the corresponding number into the "zeroable_hugepages" interface. Since the zeroing work is accounted to the application process, the CPU time it consumes can be constrained through that process's cgroup. Thanks, Zhe