show page size in /proc/$pid/numa_maps

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.

---

 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
@@ -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 [email protected]. 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:"[email protected]"> [email protected] </a>

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 [email protected]. 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:"[email protected]"> [email protected] </a>

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 [email protected]. 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:"[email protected]"> [email protected] </a>

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.