[RFC][PATCH] show page size in /proc/$pid/numa_maps

[RFC][PATCH] show page size in /proc/$pid/numa_maps

[Dave Hansen]

The output of /proc/$pid/numa_maps is in terms of number of pages
like anon=22 or dirty=54.  Here's some output:

7f4680000000 default file=/hugetlb/bigfile anon=50 dirty=50 N0=50
7f7659600000 default file=/anon_hugepage\040(deleted) anon=50 dirty=50 N0=50
7fff8d425000 default stack anon=50 dirty=50 N0=50

Looks like we have a stack and a couple of anonymous hugetlbfs
areas page which both use the same amount of memory.  They don't.

The 'bigfile' uses 1GB pages and takes up ~50GB of space.  The
anon_hugepage uses 2MB pages and takes up ~100MB of space while
the stack uses normal 4k pages.  You can go over to smaps to
figure out what the page size _really_ is with KernelPageSize
or MMUPageSize.  But, I think this is a pretty nasty and
counterintuitive interface as it stands.

The following patch adds a pagemult= field.  It is placed only
in cases where the VMA's page size differs from the base kernel
page size.  I'm calling it pagemult to emphasize that it is
indended to modify the statistics output rather than _really_
show the page size that the kernel or MMU is using.

Signed-off-by: Dave Haneen <dave@linux.vnet.ibm.com>
---

 linux-2.6.git-dave/fs/proc/task_mmu.c |    7 +++++++
 1 file changed, 7 insertions(+)

diff -puN fs/proc/task_mmu.c~show-page-size fs/proc/task_mmu.c
--- linux-2.6.git/fs/proc/task_mmu.c~show-page-size	2011-09-21 15:05:49.846739432 -0700
+++ linux-2.6.git-dave/fs/proc/task_mmu.c	2011-09-21 15:10:26.798329158 -0700
@@ -1007,6 +1007,7 @@ static int show_numa_map(struct seq_file
 	struct mm_struct *mm = vma->vm_mm;
 	struct mm_walk walk = {};
 	struct mempolicy *pol;
+	unsigned long pagesize_multiplier;
 	int n;
 	char buffer[50];
 
@@ -1044,6 +1045,12 @@ static int show_numa_map(struct seq_file
 	if (!md->pages)
 		goto out;
 
+	/* This will only really do something for hugetlbfs pages.
+	 * Transparent hugepages are still pagemult=1 */
+	pagesize_multiplier = vma_kernel_pagesize(vma) / PAGE_SIZE;
+	if (pagesize_multiplier > 1)
+		seq_printf(m, " pagemult=%lu", pagesize_multiplier);
+
 	if (md->anon)
 		seq_printf(m, " anon=%lu", md->anon);
 
_

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [RFC][PATCH] show page size in /proc/$pid/numa_maps

[David Rientjes]

On Wed, 21 Sep 2011, Dave Hansen wrote:

> 
> The output of /proc/$pid/numa_maps is in terms of number of pages
> like anon=22 or dirty=54.  Here's some output:
> 
> 7f4680000000 default file=/hugetlb/bigfile anon=50 dirty=50 N0=50
> 7f7659600000 default file=/anon_hugepage\040(deleted) anon=50 dirty=50 N0=50
> 7fff8d425000 default stack anon=50 dirty=50 N0=50
> 
> Looks like we have a stack and a couple of anonymous hugetlbfs
> areas page which both use the same amount of memory.  They don't.
> 
> The 'bigfile' uses 1GB pages and takes up ~50GB of space.  The
> anon_hugepage uses 2MB pages and takes up ~100MB of space while
> the stack uses normal 4k pages.  You can go over to smaps to
> figure out what the page size _really_ is with KernelPageSize
> or MMUPageSize.  But, I think this is a pretty nasty and
> counterintuitive interface as it stands.
> 
> The following patch adds a pagemult= field.  It is placed only
> in cases where the VMA's page size differs from the base kernel
> page size.  I'm calling it pagemult to emphasize that it is
> indended to modify the statistics output rather than _really_
> show the page size that the kernel or MMU is using.
> 

Why not just add a pagesize={4K,2M,1G,...} field for every output?

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [RFC][PATCH] show page size in /proc/$pid/numa_maps

[Dave Hansen]

On Thu, 2011-09-22 at 13:43 -0700, David Rientjes wrote:
> Why not just add a pagesize={4K,2M,1G,...} field for every output? 

I think it's a bit misleading.  With THP at least we have 2M pages in
the MMU, but we're reporting in 4k units.

I certainly considered doing just what you're suggesting, though.  It's
definitely not a bad idea.  Certainly much more clear.

-- Dave

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [RFC][PATCH] show page size in /proc/$pid/numa_maps

[David Rientjes]

On Fri, 23 Sep 2011, Dave Hansen wrote:

> > Why not just add a pagesize={4K,2M,1G,...} field for every output? 
> 
> I think it's a bit misleading.  With THP at least we have 2M pages in
> the MMU, but we're reporting in 4k units.
> 
> I certainly considered doing just what you're suggesting, though.  It's
> definitely not a bad idea.  Certainly much more clear.
> 

Een though the code is in task_mmu.c, I think that /proc/pid/numa_maps 
should be more representative of the state of vmas where any 
pagesize={4K,2M,1G,...} would be true rather than whether or not the mmu 
sees tham as large or small pages.  I actually don't see much difference 
between anon=50 pagemult=512 and anon=50 pagesize=2M, but I'd definitely 
recommend printing the field for every vma.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>