From: Sourav Panda <souravpanda@google.com>
To: muchun.song@linux.dev, osalvador@suse.de, akpm@linux-foundation.org
Cc: david@kernel.org, ljs@kernel.org, liam@infradead.org,
vbabka@kernel.org, rppt@kernel.org, surenb@google.com,
mhocko@suse.com, mst@redhat.com, mhklinux@outlook.com,
souravpanda@google.com, fvdl@google.com, gthelen@google.com,
mike.kravetz@oracle.com, pasha.tatashin@soleen.com,
rientjes@google.com, riel@surriel.com, linux-mm@kvack.org,
linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org,
linux-doc@vger.kernel.org
Subject: [PATCH 5/6] Documentation/admin-guide/mm/hugetlbpage.rst: document cache interfaces
Date: Tue, 7 Jul 2026 06:42:34 +0000 [thread overview]
Message-ID: <20260707064235.1386552-6-souravpanda@google.com> (raw)
In-Reply-To: <20260707064235.1386552-1-souravpanda@google.com>
Document the newly introduced sysfs interfaces for the HugeTLB
dynamic cache. This includes max_cached_huge_pages,
nr_cached_hugepages and their NUMA/mempolicy variants.
Signed-off-by: Sourav Panda <souravpanda@google.com>
---
Documentation/admin-guide/mm/hugetlbpage.rst | 34 ++++++++++++++++++--
1 file changed, 32 insertions(+), 2 deletions(-)
diff --git a/Documentation/admin-guide/mm/hugetlbpage.rst b/Documentation/admin-guide/mm/hugetlbpage.rst
index 67a941903fd2..6b96779e2584 100644
--- a/Documentation/admin-guide/mm/hugetlbpage.rst
+++ b/Documentation/admin-guide/mm/hugetlbpage.rst
@@ -264,6 +264,10 @@ pages may exist::
free_hugepages
resv_hugepages
surplus_hugepages
+ max_cached_huge_pages
+ max_cached_huge_pages_mempolicy
+ nr_cached_hugepages
+ nr_cached_hugepages_mempolicy
The demote interfaces provide the ability to split a huge page into
smaller huge pages. For example, the x86 architecture supports both
@@ -286,8 +290,28 @@ demote
actually demoted, compare the value of nr_hugepages before and after
writing to the demote interface. demote is a write only interface.
-The interfaces which are the same as in ``/proc`` (all except demote and
-demote_size) function as described above for the default huge page-sized case.
+max_cached_huge_pages
+ is the maximum number of cached hugepages for this size (global).
+ Surplus hugepages freed by applications are recycled into this cache
+ instead of being released back to the buddy allocator immediately.
+ Subsequent allocations for surplus pages will prefer this cache.
+ A user with root privileges can write to this file to set the limit.
+ This interface accepts absolute values as well as relative adjustments
+ using +1 or -1.
+
+max_cached_huge_pages_mempolicy
+ is the same as max_cached_huge_pages, but the nodes from which pages
+ are cached are controlled by the memory policy of the task.
+
+nr_cached_hugepages
+ reports the current number of cached hugepages. Writing to this file
+ allows manual expansion or contraction of the cache.
+ A user with root privileges can write to this file.
+ This interface accepts absolute values as well as relative adjustments
+ using +1 or -1.
+
+nr_cached_hugepages_mempolicy
+ is the same as nr_cached_hugepages, but obeys the memory policy.
+
+The interfaces which are the same as in ``/proc`` (all except demote,
+demote_size, and the cache interfaces) function as described above
+for the default huge page-sized case.
.. _mem_policy_and_hp_alloc:
@@ -372,6 +396,8 @@ contains the following attribute files::
nr_hugepages
free_hugepages
surplus_hugepages
+ nr_cached_hugepages
+ max_cached_huge_pages
The free\_' and surplus\_' attribute files are read-only. They return the number
of free and surplus [overcommitted] huge pages, respectively, on the parent
@@ -382,6 +408,10 @@ specified node. When this attribute is written, the number of persistent huge
pages on the parent node will be adjusted to the specified value, if sufficient
resources exist, regardless of the task's mempolicy or cpuset constraints.
+The ``nr_cached_hugepages`` and ``max_cached_huge_pages`` attributes return the
+number of cached huge pages and the max limit on the specified node, respectively.
+Writing to these attributes adjusts the cache on the parent node.
+
Note that the number of overcommit and reserve pages remain global quantities,
as we don't know until fault time, when the faulting task's mempolicy is
applied, from which node the huge page allocation will be attempted.
--
2.55.0.rc0.799.gd6f94ed593-goog
next prev parent reply other threads:[~2026-07-07 6:42 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-07 6:42 [RFC PATCH 0/6] mm/hugetlb: Dynamic, NUMA-aware HugePage Cache & Free Page Reporting Sourav Panda
2026-07-07 6:42 ` [PATCH 1/6] mm/hugetlb: add Kconfig and basic cache infrastructure Sourav Panda
2026-07-07 6:42 ` [PATCH 2/6] mm/hugetlb: implement cache recycling and allocation Sourav Panda
2026-07-07 6:42 ` [PATCH 3/6] mm/hugetlb: add sysfs interfaces for cache Sourav Panda
2026-07-07 6:42 ` [PATCH 4/6] mm/hugetlb: add memory shrinker " Sourav Panda
2026-07-07 6:42 ` Sourav Panda [this message]
2026-07-07 6:42 ` [PATCH 6/6] mm/hugetlb: support free page reporting for cached hugepages Sourav Panda
2026-07-07 7:18 ` Michael S. Tsirkin
2026-07-07 10:18 ` Michael S. Tsirkin
2026-07-07 6:56 ` [RFC PATCH 0/6] mm/hugetlb: Dynamic, NUMA-aware HugePage Cache & Free Page Reporting Michael S. Tsirkin
2026-07-07 7:21 ` Sourav Panda
2026-07-07 7:29 ` David Hildenbrand (Arm)
2026-07-07 8:09 ` Muchun Song
2026-07-07 10:25 ` Michael S. Tsirkin
2026-07-07 10:28 ` David Hildenbrand (Arm)
2026-07-07 11:06 ` Lorenzo Stoakes
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260707064235.1386552-6-souravpanda@google.com \
--to=souravpanda@google.com \
--cc=akpm@linux-foundation.org \
--cc=david@kernel.org \
--cc=fvdl@google.com \
--cc=gthelen@google.com \
--cc=liam@infradead.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=ljs@kernel.org \
--cc=mhklinux@outlook.com \
--cc=mhocko@suse.com \
--cc=mike.kravetz@oracle.com \
--cc=mst@redhat.com \
--cc=muchun.song@linux.dev \
--cc=osalvador@suse.de \
--cc=pasha.tatashin@soleen.com \
--cc=riel@surriel.com \
--cc=rientjes@google.com \
--cc=rppt@kernel.org \
--cc=surenb@google.com \
--cc=vbabka@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox