From: Andi Kleen <ak@linux.intel.com>
To: linux-mm@kvack.org
Cc: akpm@linux-foundation.org, Andi Kleen <ak@linux.intel.com>
Subject: [PATCH v2] smaps: Report correct page sizes with THP
Date: Wed, 25 Feb 2026 15:27:08 -0800 [thread overview]
Message-ID: <20260225232708.87833-1-ak@linux.intel.com> (raw)
The earlier version of this patch kit wasn't that well received,
with the main objection being non support for mTHP. This variant
tracks any mTHP sizes in a VMA and reports them with MMUPageSizeN in smaps,
with increasing N. The base page size is still reported w/o a
number postfix to stay compatible.
The nice thing is that the patch is actually simpler and more
straight forward than the THP only variant. Also improved the
documentation.
Recently I wasted quite some time debugging why THP didn't work, when it
was just smaps always reporting the base page size. It has separate
counts for (non m) THP, but using them is not always obvious.
I left KernelPageSize alone.
Signed-off-by: Andi Kleen <ak@linux.intel.com>
---
Documentation/filesystems/proc.rst | 8 ++++++--
fs/proc/task_mmu.c | 14 +++++++++++++-
2 files changed, 19 insertions(+), 3 deletions(-)
diff --git a/Documentation/filesystems/proc.rst b/Documentation/filesystems/proc.rst
index b0c0d1b45b99..c5102ef7a2eb 100644
--- a/Documentation/filesystems/proc.rst
+++ b/Documentation/filesystems/proc.rst
@@ -452,6 +452,7 @@ Memory Area, or VMA) there is a series of lines such as the following::
Size: 1084 kB
KernelPageSize: 4 kB
MMUPageSize: 4 kB
+ MMUPageSize2: 2048 kB
Rss: 892 kB
Pss: 374 kB
Pss_Dirty: 0 kB
@@ -476,14 +477,17 @@ Memory Area, or VMA) there is a series of lines such as the following::
VmFlags: rd ex mr mw me dw
The first of these lines shows the same information as is displayed for
-the mapping in /proc/PID/maps. Following lines show the size of the
+the mapping in /proc/PID/maps (except that there might be more page sizes
+if the mapping has them)
+Following lines show the size of the
mapping (size); the size of each page allocated when backing a VMA
(KernelPageSize), which is usually the same as the size in the page table
entries; the page size used by the MMU when backing a VMA (in most cases,
the same as KernelPageSize); the amount of the mapping that is currently
resident in RAM (RSS); the process's proportional share of this mapping
(PSS); and the number of clean and dirty shared and private pages in the
-mapping.
+mapping. If the mapping has multiple page size there might be a be multiple
+numbered MMUPageSize entries.
The "proportional set size" (PSS) of a process is the count of pages it has
in memory, where each page is divided by the number of processes sharing it.
diff --git a/fs/proc/task_mmu.c b/fs/proc/task_mmu.c
index e091931d7ca1..8bfd8b13c2ed 100644
--- a/fs/proc/task_mmu.c
+++ b/fs/proc/task_mmu.c
@@ -874,6 +874,7 @@ struct mem_size_stats {
unsigned long shared_hugetlb;
unsigned long private_hugetlb;
unsigned long ksm;
+ unsigned long compound_orders;
u64 pss;
u64 pss_anon;
u64 pss_file;
@@ -942,6 +943,9 @@ static void smaps_account(struct mem_size_stats *mss, struct page *page,
if (young || folio_test_young(folio) || folio_test_referenced(folio))
mss->referenced += size;
+ mss->compound_orders |=
+ BIT_ULL(compound ? folio_large_order(folio) : 0);
+
/*
* Then accumulate quantities that may depend on sharing, or that may
* differ page-by-page.
@@ -1371,6 +1375,7 @@ static int show_smap(struct seq_file *m, void *v)
{
struct vm_area_struct *vma = v;
struct mem_size_stats mss = {};
+ int i, cnt = 0;
smap_gather_stats(vma, &mss, 0);
@@ -1378,7 +1383,14 @@ static int show_smap(struct seq_file *m, void *v)
SEQ_PUT_DEC("Size: ", vma->vm_end - vma->vm_start);
SEQ_PUT_DEC(" kB\nKernelPageSize: ", vma_kernel_pagesize(vma));
- SEQ_PUT_DEC(" kB\nMMUPageSize: ", vma_mmu_pagesize(vma));
+
+ for_each_set_bit(i, &mss.compound_orders, BITS_PER_LONG) {
+ if (cnt++ == 0)
+ SEQ_PUT_DEC(" kB\nMMUPageSize: ", PAGE_SIZE << i);
+ else
+ seq_printf(m, " kB\nMMUPageSize%d: %8u",
+ cnt, 1 << (PAGE_SHIFT-10+i));
+ }
seq_puts(m, " kB\n");
__show_smap(m, &mss, false);
--
2.53.0
reply other threads:[~2026-02-25 23:27 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=20260225232708.87833-1-ak@linux.intel.com \
--to=ak@linux.intel.com \
--cc=akpm@linux-foundation.org \
--cc=linux-mm@kvack.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