linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
* [PATCH] smaps: Report correct page sizes with THP
@ 2026-02-09 20:17 Andi Kleen
  2026-02-12 12:42 ` David Hildenbrand (Arm)
  2026-02-21  0:03 ` jane.chu
  0 siblings, 2 replies; 5+ messages in thread
From: Andi Kleen @ 2026-02-09 20:17 UTC (permalink / raw)
  To: linux-mm; +Cc: linux-fsdevel, akpm, willy, Andi Kleen

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. For
standard THP the page sizes can be actually derived from the existing
counts, so do just do that. I left KernelPageSize alone.
The mixed page size case is reported with a new MMUPageSize2 item.
This doesn't do anything about mTHP reporting, but even the basic
smaps is not aware of it so far.

Signed-off-by: Andi Kleen <ak@linux.intel.com>
---
 Documentation/filesystems/proc.rst |  2 +-
 fs/proc/task_mmu.c                 | 14 +++++++++++++-
 2 files changed, 14 insertions(+), 2 deletions(-)

diff --git a/Documentation/filesystems/proc.rst b/Documentation/filesystems/proc.rst
index 8256e857e2d7..7c776046d15a 100644
--- a/Documentation/filesystems/proc.rst
+++ b/Documentation/filesystems/proc.rst
@@ -483,7 +483,7 @@ 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 MMUPageSize2.
 
 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 26188a4ad1ab..9123e59dcf4c 100644
--- a/fs/proc/task_mmu.c
+++ b/fs/proc/task_mmu.c
@@ -1377,7 +1377,19 @@ 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));
+
+	/* Only THP? */
+	if (mss.shmem_thp + mss.file_thp + mss.anonymous_thp == mss.resident &&
+	    mss.resident > 0) {
+		SEQ_PUT_DEC(" kB\nMMUPageSize:    ", HPAGE_PMD_SIZE);
+	} else {
+		unsigned ps = vma_mmu_pagesize(vma);
+		/* Will need adjustments when more THP page sizes are added. */
+		SEQ_PUT_DEC(" kB\nMMUPageSize:    ", ps);
+		if (mss.shmem_thp + mss.file_thp + mss.anonymous_thp > 0 &&
+		    ps != HPAGE_PMD_SIZE)
+			SEQ_PUT_DEC(" kB\nMMUPageSize2:   ", HPAGE_PMD_SIZE);
+	}
 	seq_puts(m, " kB\n");
 
 	__show_smap(m, &mss, false);
-- 
2.52.0



^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [PATCH] smaps: Report correct page sizes with THP
  2026-02-09 20:17 [PATCH] smaps: Report correct page sizes with THP Andi Kleen
@ 2026-02-12 12:42 ` David Hildenbrand (Arm)
  2026-02-12 17:58   ` Andi Kleen
  2026-02-21  0:03 ` jane.chu
  1 sibling, 1 reply; 5+ messages in thread
From: David Hildenbrand (Arm) @ 2026-02-12 12:42 UTC (permalink / raw)
  To: Andi Kleen, linux-mm; +Cc: linux-fsdevel, akpm, willy

On 2/9/26 21:17, Andi Kleen wrote:
> 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. For
> standard THP the page sizes can be actually derived from the existing
> counts, so do just do that. I left KernelPageSize alone.
> The mixed page size case is reported with a new MMUPageSize2 item.
> This doesn't do anything about mTHP reporting, but even the basic
> smaps is not aware of it so far.
> 
> Signed-off-by: Andi Kleen <ak@linux.intel.com>
> ---
>   Documentation/filesystems/proc.rst |  2 +-
>   fs/proc/task_mmu.c                 | 14 +++++++++++++-
>   2 files changed, 14 insertions(+), 2 deletions(-)
> 
> diff --git a/Documentation/filesystems/proc.rst b/Documentation/filesystems/proc.rst
> index 8256e857e2d7..7c776046d15a 100644
> --- a/Documentation/filesystems/proc.rst
> +++ b/Documentation/filesystems/proc.rst
> @@ -483,7 +483,7 @@ 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 MMUPageSize2.
>   
>   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 26188a4ad1ab..9123e59dcf4c 100644
> --- a/fs/proc/task_mmu.c
> +++ b/fs/proc/task_mmu.c
> @@ -1377,7 +1377,19 @@ 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));
> +
> +	/* Only THP? */
> +	if (mss.shmem_thp + mss.file_thp + mss.anonymous_thp == mss.resident &&
> +	    mss.resident > 0) {
> +		SEQ_PUT_DEC(" kB\nMMUPageSize:    ", HPAGE_PMD_SIZE);
> +	} else {
> +		unsigned ps = vma_mmu_pagesize(vma);
> +		/* Will need adjustments when more THP page sizes are added. */
> +		SEQ_PUT_DEC(" kB\nMMUPageSize:    ", ps);
> +		if (mss.shmem_thp + mss.file_thp + mss.anonymous_thp > 0 &&
> +		    ps != HPAGE_PMD_SIZE)
> +			SEQ_PUT_DEC(" kB\nMMUPageSize2:   ", HPAGE_PMD_SIZE);
> +	}
>   	seq_puts(m, " kB\n");
>   
>   	__show_smap(m, &mss, false);

We have AnonHugePages:, ShmemPmdMapped: and FilePmdMapped: that tell you 
exactly what you want to know.

Especially the mixed thing is just nasty.

Once we go into cont-pte territory (or automatic pte coalescing by 
hardware) it all gets confusing.

Sorry, NAK.

-- 
Cheers,

David


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [PATCH] smaps: Report correct page sizes with THP
  2026-02-12 12:42 ` David Hildenbrand (Arm)
@ 2026-02-12 17:58   ` Andi Kleen
  2026-02-12 18:05     ` David Hildenbrand (Arm)
  0 siblings, 1 reply; 5+ messages in thread
From: Andi Kleen @ 2026-02-12 17:58 UTC (permalink / raw)
  To: David Hildenbrand (Arm); +Cc: linux-mm, linux-fsdevel, akpm, willy

> We have AnonHugePages:, ShmemPmdMapped: and FilePmdMapped: that tell you
> exactly what you want to know.

.... if you know about it. I personally wasted a lot of time on it
because we trusted a lie.

> 
> Especially the mixed thing is just nasty.
> 
> Once we go into cont-pte territory (or automatic pte coalescing by hardware)
> it all gets confusing.

In this case it can be extended to more.

> 
> Sorry, NAK.

Okay then just remove the page size if it's fictional outside hugetlb anyways? 

I can send that patch too, but it would seem inferior.

-Andi



^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [PATCH] smaps: Report correct page sizes with THP
  2026-02-12 17:58   ` Andi Kleen
@ 2026-02-12 18:05     ` David Hildenbrand (Arm)
  0 siblings, 0 replies; 5+ messages in thread
From: David Hildenbrand (Arm) @ 2026-02-12 18:05 UTC (permalink / raw)
  To: Andi Kleen; +Cc: linux-mm, linux-fsdevel, akpm, willy

On 2/12/26 18:58, Andi Kleen wrote:
>> We have AnonHugePages:, ShmemPmdMapped: and FilePmdMapped: that tell you
>> exactly what you want to know.
> 
> .... if you know about it. I personally wasted a lot of time on it
> because we trusted a lie.

It is confusing, I agree. I don't know why we added it in the first place.

> 
>>
>> Especially the mixed thing is just nasty.
>>
>> Once we go into cont-pte territory (or automatic pte coalescing by hardware)
>> it all gets confusing.
> 
> In this case it can be extended to more.
> 
>>
>> Sorry, NAK.
> 
> Okay then just remove the page size if it's fictional outside hugetlb anyways?

I'm sure that would break some tooling.

-- 
Cheers,

David


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [PATCH] smaps: Report correct page sizes with THP
  2026-02-09 20:17 [PATCH] smaps: Report correct page sizes with THP Andi Kleen
  2026-02-12 12:42 ` David Hildenbrand (Arm)
@ 2026-02-21  0:03 ` jane.chu
  1 sibling, 0 replies; 5+ messages in thread
From: jane.chu @ 2026-02-21  0:03 UTC (permalink / raw)
  To: Andi Kleen, linux-mm; +Cc: linux-fsdevel, akpm, willy


On 2/9/2026 12:17 PM, Andi Kleen wrote:
> 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. For
> standard THP the page sizes can be actually derived from the existing
> counts, so do just do that. I left KernelPageSize alone.
> The mixed page size case is reported with a new MMUPageSize2 item.
> This doesn't do anything about mTHP reporting, but even the basic
> smaps is not aware of it so far.
> 
> Signed-off-by: Andi Kleen <ak@linux.intel.com>
> ---
>   Documentation/filesystems/proc.rst |  2 +-
>   fs/proc/task_mmu.c                 | 14 +++++++++++++-
>   2 files changed, 14 insertions(+), 2 deletions(-)
> 
> diff --git a/Documentation/filesystems/proc.rst b/Documentation/filesystems/proc.rst
> index 8256e857e2d7..7c776046d15a 100644
> --- a/Documentation/filesystems/proc.rst
> +++ b/Documentation/filesystems/proc.rst
> @@ -483,7 +483,7 @@ 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 MMUPageSize2.
>   
>   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 26188a4ad1ab..9123e59dcf4c 100644
> --- a/fs/proc/task_mmu.c
> +++ b/fs/proc/task_mmu.c
> @@ -1377,7 +1377,19 @@ 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));
> +
> +	/* Only THP? */
> +	if (mss.shmem_thp + mss.file_thp + mss.anonymous_thp == mss.resident &&
> +	    mss.resident > 0) {
> +		SEQ_PUT_DEC(" kB\nMMUPageSize:    ", HPAGE_PMD_SIZE);
> +	} else {
> +		unsigned ps = vma_mmu_pagesize(vma);
> +		/* Will need adjustments when more THP page sizes are added. */
> +		SEQ_PUT_DEC(" kB\nMMUPageSize:    ", ps);
> +		if (mss.shmem_thp + mss.file_thp + mss.anonymous_thp > 0 &&
> +		    ps != HPAGE_PMD_SIZE)
> +			SEQ_PUT_DEC(" kB\nMMUPageSize2:   ", HPAGE_PMD_SIZE);
> +	}
>   	seq_puts(m, " kB\n");
>   
>   	__show_smap(m, &mss, false);

Looks good to me.
While you're at this, maybe you could remove the redundant entries in 
the documentation?
     452     Size:               1084 kB
     453     KernelPageSize:        4 kB
     454     MMUPageSize:           4 kB
     455     Rss:                 892 kB
     456     Pss:                 374 kB
[..]
     472     KernelPageSize:        4 kB	<--
     473     MMUPageSize:           4 kB	<--

Reviewed-by: Jane Chu <jane.chu@oracle.com>

thanks,
-jane





^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2026-02-21  0:03 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2026-02-09 20:17 [PATCH] smaps: Report correct page sizes with THP Andi Kleen
2026-02-12 12:42 ` David Hildenbrand (Arm)
2026-02-12 17:58   ` Andi Kleen
2026-02-12 18:05     ` David Hildenbrand (Arm)
2026-02-21  0:03 ` jane.chu

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox