smaps: Report correct page sizes with THP

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 <[email protected]>

---
 Documentation/filesystems/proc.rst |  8 ++++++--
 fs/proc/task_mmu.c                 | 14 +++++++++++++-
 2 files changed, 19 insertions(+), 3 deletions(-)

Documentation/filesystems/proc.rst +6 -2

index b0c0d1b45b99..c5102ef7a2eb 100644
@@ -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.

fs/proc/task_mmu.c +5 -0

index e091931d7ca1..8bfd8b13c2ed 100644
@@ -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);
 

fs/proc/task_mmu.c +6 -0

+		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);

Signature · 1 line

2.53.0

When a VMA has no resident pages (e.g., freshly mmap'd but not yet faulted), compound_orders will be zero and the for_each_set_bit loop will not execute at all. This means no MMUPageSize line is emitted for that VMA.

Previously, vma_mmu_pagesize() was called unconditionally and always produced the MMUPageSize field. Userspace tools that parse smaps and expect MMUPageSize to always be present would break on VMAs with no resident pages. Should we always add it?

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 <[email protected]>

---

a) Just because a folio has a certain order does not imply that hw actually coalesces anything. MMUPageSize is otherwise misleading.

b) Simply because you find a folio of a certain order does not imply that it is even fully mapped in there.

c) PTE coalescing on AMD can even span folios

But more importantly

d) MMUPageSize is independent of the actual page mappings, and I don't think we should change these semantics.

Let's see why MMUPageSize was added in the first place:

commit 3340289ddf29ca75c3acfb3a6b72f234b2f74d5c

Author: Mel Gorman <[email protected]>
Date:   Tue Jan 6 14:38:54 2009 -0800

mm: report the MMU pagesize in /proc/pid/smaps

The KernelPageSize entry in /proc/pid/smaps is the pagesize used by the kernel to back a VMA. This matches the size used by the MMU in the majority of cases. However, one counter-example occurs on PPC64 kernels whereby a kernel using 64K as a base pagesize may still use 4K pages for the MMU on older processor. To distinguish, this patch reports MMUPageSize as the pagesize used by the MMU in /proc/pid/smaps.

So instead of 64K (PAGE_SIZE), they reported 4K. Always. Even if nothing is mapped.

So you could indicate all MMUPageSize that hardware possibly supports in here. I don't think it's that helpful.

We once discussed exporting more stats here (similar to AnonHugePages/ShmemPmdMapped, ...) but we were concerned about creating a mess with mTHP stats.

For this reason, Ryan developed a tool (tools/mm/thpmaps) to introspect the actual mappings.

Quoted 5 lines

But more importantly

d) MMUPageSize is independent of the actual page mappings, and I don't think we should change these semantics.

That makes no sense. What is it good for then? Just a random number that looks good?

Quoted 19 lines

Let's see why MMUPageSize was added in the first place:

commit 3340289ddf29ca75c3acfb3a6b72f234b2f74d5c

Author: Mel Gorman <[email protected]>
Date:   Tue Jan 6 14:38:54 2009 -0800

mm: report the MMU pagesize in /proc/pid/smaps

The KernelPageSize entry in /proc/pid/smaps is the pagesize used by the kernel to back a VMA. This matches the size used by the MMU in the majority of cases. However, one counter-example occurs on PPC64 kernels whereby a kernel using 64K as a base pagesize may still use 4K pages for the MMU on older processor. To distinguish, this patch reports MMUPageSize as the pagesize used by the MMU in /proc/pid/smaps.

Quoted 1 line

So instead of 64K (PAGE_SIZE), they reported 4K. Always. Even if nothing is mapped.

It doesn't seem like a good design. I don't know what that is good for.

What is reasonable to report something at least approximating what is really mapped.

Quoted 7 lines

We once discussed exporting more stats here (similar to AnonHugePages/ShmemPmdMapped, ...) but we were concerned about creating a mess with mTHP stats.

For this reason, Ryan developed a tool (tools/mm/thpmaps) to introspect the actual mappings.

Some magic other tool doesn't help with the current output confusing people.

Especially after reading 3340289ddf29ca75c3acfb3a6b72f234b2f74d5c I ended up with he following conclusion:

"KernelPageSize" tells you in which granularity we can mmap()/munmap() etc. Simple.

"MMUPageSize" tells us how this granularity is implemented (or emulated) under the hood.

The case we care about is when MMUPageSize < KernelPageSize. A process might have to know that detail even when nothing is currently/yet faulted in.

Assume a process would perform an atomic that would cross MMUPageSize, but not KernelPageSize. Depending on the architecture, atomics would not work as expected in that case.

I'd expect other cases where an architecture might have to care about the actual, smallest possible MMUPageSize it might be executed on while running the program.

It's a shame we had to add MMUPageSize, but maybe it might resurface if we ever support emulating 64K/16K user pagesizes on 4K MMUs.

Adding more confusion with this MMUPageSize extension is not an option. We should likely clarify what MMUPageSize really means.

Quoted 13 lines

Especially after reading 3340289ddf29ca75c3acfb3a6b72f234b2f74d5c I ended up with he following conclusion:

"KernelPageSize" tells you in which granularity we can mmap()/munmap() etc. Simple.

"MMUPageSize" tells us how this granularity is implemented (or emulated) under the hood.

The case we care about is when MMUPageSize < KernelPageSize. A process might have to know that detail even when nothing is currently/yet faulted in.

Quoted 3 lines

Assume a process would perform an atomic that would cross MMUPageSize, but not KernelPageSize. Depending on the architecture, atomics would not work as expected in that case.

I thought most architectures don't support atomics crossing pages anyways. x86 supports it, but it's discouraged.

Quoted 5 lines

I'd expect other cases where an architecture might have to care about the actual, smallest possible MMUPageSize it might be executed on while running the program.

That's fine, they can use the min, or just the first match (which is always the smallest)

Quoted 1 line

Quoted 2 lines

It's a shame we had to add MMUPageSize, but maybe it might resurface if we ever support emulating 64K/16K user pagesizes on 4K MMUs.

Okay, so if I follow that correctly you're suggesting to change KernelPageSize, not MMUPageSize. I can do that change.

Quoted 17 lines · Andi Kleen

Quoted 16 lines

Especially after reading 3340289ddf29ca75c3acfb3a6b72f234b2f74d5c I ended up with he following conclusion:

"KernelPageSize" tells you in which granularity we can mmap()/munmap() etc. Simple.

"MMUPageSize" tells us how this granularity is implemented (or emulated) under the hood.

The case we care about is when MMUPageSize < KernelPageSize. A process might have to know that detail even when nothing is currently/yet faulted in.

Assume a process would perform an atomic that would cross MMUPageSize, but not KernelPageSize. Depending on the architecture, atomics would not work as expected in that case.

Quoted 2 lines

I thought most architectures don't support atomics crossing pages anyways. x86 supports it, but it's discouraged.

Right. And if your user space thinks it has "64k" pages, when it's actually emulated through "4k" pages under the hood, that could be a
problem: user space could perform an atomic "within" a 64k page that

actually crosses two 4k pages. So it must be aware that mmap etc operate in 64k, but the underlying emulation might be smaller.

Quoted 8 lines

Quoted 3 lines

I'd expect other cases where an architecture might have to care about the actual, smallest possible MMUPageSize it might be executed on while running the program.

That's fine, they can use the min, or just the first match (which is always the smallest)

Quoted 1 line

Quoted 5 lines

Quoted 2 lines

It's a shame we had to add MMUPageSize, but maybe it might resurface if we ever support emulating 64K/16K user pagesizes on 4K MMUs.

Okay, so if I follow that correctly you're suggesting to change KernelPageSize, not MMUPageSize. I can do that change.

Not at all. I'm saying that we leave KernelPageSize and MMUPageSize alone, just as they are today.

Instead, if we want better statistics (and I think we want) regarding how things are mapped, we should look into a better interface.

Ideally, that will tell you "how much" of a certain contiguous size is mapped, if that contiguous size benefits somehow from TLB optimizations, etc.

Quoted 3 lines

Ideally, that will tell you "how much" of a certain contiguous size is mapped, if that contiguous size benefits somehow from TLB optimizations, etc.

The key word is "somehow". It's better to work with real use cases instead of such hypothetics.

Quoted 18 lines · David Hildenbrand (Arm)

Quoted 17 lines · Andi Kleen

Quoted 16 lines

Especially after reading 3340289ddf29ca75c3acfb3a6b72f234b2f74d5c I ended up with he following conclusion:

"KernelPageSize" tells you in which granularity we can mmap()/munmap() etc. Simple.

"MMUPageSize" tells us how this granularity is implemented (or emulated) under the hood.

The case we care about is when MMUPageSize < KernelPageSize. A process might have to know that detail even when nothing is currently/yet faulted in.

Assume a process would perform an atomic that would cross MMUPageSize, but not KernelPageSize. Depending on the architecture, atomics would not work as expected in that case.

Quoted 6 lines

Quoted 2 lines

I thought most architectures don't support atomics crossing pages anyways. x86 supports it, but it's discouraged.

Right. And if your user space thinks it has "64k" pages, when it's actually emulated through "4k" pages under the hood, that could be a
problem: user space could perform an atomic "within" a 64k page that

PPC user space doesn't do it.

Quoted 2 lines

actually crosses two 4k pages. So it must be aware that mmap etc operate in 64k, but the underlying emulation might be smaller.

Sounds like a very contrived use case, which I'm not sure actually happens. From my past experiences most software usually doesn't use complicated enumerations anyways but just hard codes something reasonable (like in your example just always assume 4K worst case). From their POV it makes sense, how would you test
a complicated enumeration for cases that don't happen on your current system.

Quoted 12 lines

Quoted 12 lines

Quoted 4 lines

I'd expect other cases where an architecture might have to care about the actual, smallest possible MMUPageSize it might be executed on while running the program.

That's fine, they can use the min, or just the first match (which is always the smallest)

Quoted 3 lines

It's a shame we had to add MMUPageSize, but maybe it might resurface if we ever support emulating 64K/16K user pagesizes on 4K MMUs.

Quoted 5 lines

Quoted 2 lines

Okay, so if I follow that correctly you're suggesting to change KernelPageSize, not MMUPageSize. I can do that change.

Not at all. I'm saying that we leave KernelPageSize and MMUPageSize alone, just as they are today.

That doesn't solve the problem that motivated my patch smaps is confusing today and would stay so.

Quoted 4 lines

Instead, if we want better statistics (and I think we want) regarding how things are mapped, we should look into a better interface.

I don't see how a new interface helps really. Some of the problems

you mentioned earlier could be either solved today with smaps (e.g. handling the case when a folio is mapped partially and just report the smaller page size), or are unsolveable in the general case (what the TLB actually handles)

A new interface doesn't really change anything given that smaps is extensible.

I'll look at the partial folio case, but will only handle it if it's simple.

Quoted 4 lines

Ideally, that will tell you "how much" of a certain contiguous size is mapped, if that contiguous size benefits somehow from TLB optimizations, etc.

The key word is "somehow". It's better to work with real use cases instead of such hypothetics.

-Andi

Quoted 10 lines

Quoted 2 lines

actually crosses two 4k pages. So it must be aware that mmap etc operate in 64k, but the underlying emulation might be smaller.

Sounds like a very contrived use case, which I'm not sure actually happens. From my past experiences most software usually doesn't use complicated enumerations anyways but just hard codes something reasonable (like in your example just always assume 4K worst case). From their POV it makes sense, how would you test
a complicated enumeration for cases that don't happen on your current system.

I'm sorry but it's a legacy user-facing stat, we don't get to change it or add a

Quoted 14 lines

Quoted 14 lines

Quoted 13 lines

Quoted 3 lines

I'd expect other cases where an architecture might have to care about the actual, smallest possible MMUPageSize it might be executed on while running the program.

That's fine, they can use the min, or just the first match (which is always the smallest)

Quoted 3 lines

It's a shame we had to add MMUPageSize, but maybe it might resurface if we ever support emulating 64K/16K user pagesizes on 4K MMUs.

Okay, so if I follow that correctly you're suggesting to change KernelPageSize, not MMUPageSize. I can do that change.

Quoted 5 lines

Quoted 2 lines

Not at all. I'm saying that we leave KernelPageSize and MMUPageSize alone, just as they are today.

That doesn't solve the problem that motivated my patch smaps is confusing today and would stay so.

Except as you've been told you can find this information out in different ways.

Quoted 7 lines

Quoted 5 lines

Instead, if we want better statistics (and I think we want) regarding how things are mapped, we should look into a better interface.

I don't see how a new interface helps really. Some of the problems

I mean, you want information X, we're suggesting the providing of an interface to provide information X and... you don't see how that helps?

Quoted 5 lines

you mentioned earlier could be either solved today with smaps (e.g. handling the case when a folio is mapped partially and just report the smaller page size), or are unsolveable in the general case (what the TLB actually handles)

We're not having multiple entries in smaps for every mapping size, it's broken and ungreppable, and very liable to add additional confusion to users.

A new interface gives us flexibility to do what we want, we aren't running out of syscalls or places to put statistics.

I would rather call it a legacy user-facing lie at this point.

Thank you for rubbing salt into the wounds.

My goal was to fix the old interface to not blatantly report wrong information. A new magical interface doesn't really help with that.

If you don't like numbers I guess we can spell it out.

BTW your comment earlier about partially mapped compound pages made me reconsider the code and unless I'm missing something the accounting is all wrong for this case anyways in the current code.

The code currently calls smaps_account for every PTE, which will happily account the complete compound page

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 <[email protected]>

---
 Documentation/filesystems/proc.rst |  8 ++++++--
 fs/proc/task_mmu.c                 | 14 +++++++++++++-
 2 files changed, 19 insertions(+), 3 deletions(-)

Documentation/filesystems/proc.rst +0 -0

index b0c0d1b45b99..c5102ef7a2eb 100644

Documentation/filesystems/proc.rst +2 -1

     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)

Documentation/filesystems/proc.rst +0 -0

 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.

fs/proc/task_mmu.c +13 -2

index e091931d7ca1..8bfd8b13c2ed 100644
@@ -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