From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 1886E35D5EE for ; Thu, 22 Jan 2026 22:19:02 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769120343; cv=none; b=G93Mg1qD8+UTdPQnO5pOZWdLgDrwaGdM2PCfMKCVsjDoAQ8OxRJ5UlwUWFSIss9Fcd65scjDsolBANVnpNbMAZnMV9hRNCqEaRwygWjvEOJO+jhYZdP0LSNLzcyIN7e97rOjLeDnA2XyW3mHD4kX0tMZOvJlDvuZ/q4C62uzFcQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769120343; c=relaxed/simple; bh=6vyvXBeHPv3ZtA1GlptzUeZjv17+qL0cCQKu4626N/4=; h=Date:From:To:Cc:Subject:Message-Id:In-Reply-To:References: Mime-Version:Content-Type; b=JCpeU0R9xRMHi/vNHXuxIyprK//5C6qXhtMJrKsGgRLixtfFsITfGgsGXInBAfHFqBsJHpOcjhpecYwP0v5knSvaGfK5iDnmD7yiqTSaYn+Y+fvtK1j3b55RUX6a8+ToL+jJZYxTNCmCx8RhEBvIuUD2t1/2J1Sn01ViQbyk/jE= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b=Ho5uRbv4; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b="Ho5uRbv4" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 3EF61C116C6; Thu, 22 Jan 2026 22:19:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1769120341; bh=6vyvXBeHPv3ZtA1GlptzUeZjv17+qL0cCQKu4626N/4=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=Ho5uRbv4ImD9QPIm5FOT6ZoQk1/H+SjS3UhTiJQscMMkOW8sNpkQKXjpmRT7Ni9bB KNTjQNEUw65R0jO0JsTKJDV0UyTwzodp9Z/9bDhSO+n5MsSL9rGdyq8LRYE5e5WzIz Csq2IM4bVbUY9TaVJYH7Lxgj7wG62pgAlqFukGpo= Date: Thu, 22 Jan 2026 14:19:00 -0800 From: Andrew Morton To: "Li Zhe" Cc: , , , , Subject: Re: [PATCH] hugetlb: increase hugepage reservations when using node-specific "hugepages=" cmdline Message-Id: <20260122141900.3eb028abe20f6c31808f9b5d@linux-foundation.org> In-Reply-To: <20260122035002.79958-1-lizhe.67@bytedance.com> References: <20260122035002.79958-1-lizhe.67@bytedance.com> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; x86_64-pc-linux-gnu) 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-Transfer-Encoding: 7bit On Thu, 22 Jan 2026 11:50:02 +0800 "Li Zhe" wrote: > Commit 3dfd02c90037 ("hugetlb: increase number of reserving hugepages > via cmdline") raised the number of hugepages that can be reserved > through the boot-time "hugepages=" parameter for the non-node-specific > case, but left the node-specific form of the same parameter unchanged. > > This patch extends the same optimization to node-specific reservations. > When HugeTLB vmemmap optimization (HVO) is enabled and a node cannot > satisfy the requested hugepages, the code first releases ordinary > struct-page memory of hugepages obtained from the buddy allocator, > allowing their struct-page memory to be reclaimed and reused for > additional hugepage reservations on that node. > > This is particularly beneficial for configurations that require > identical, large per-node hugepage reservations. On a four-node, 384 GB > x86 VM, the patch raises the attainable 2 MiB hugepage reservation from > under 374 GB to more than 379 GB. > Thanks. I *think* the hugepages= documentation in Documentation/admin-guide/mm/hugetlbpage.rst is still up to date and complete, but can you please check it, see if there's somethig we should do?