The patch titled
Subject: fs: proc: task_mmu: show page size in /proc/<pid>/numa_maps
has been added to the -mm tree. Its filename is
fs-proc-task_mmu-show-page-size-in-proc-pid-numa_maps.patch
This patch should soon appear at
http://ozlabs.org/~akpm/mmots/broken-out/fs-proc-task_mmu-show-page-size-in-proc-pid-numa_maps.patch
and later at
http://ozlabs.org/~akpm/mmotm/broken-out/fs-proc-task_mmu-show-page-size-in-proc-pid-numa_maps.patch
Before you just go and hit "reply", please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/SubmitChecklist when testing your code ***
The -mm tree is included into linux-next and is updated
there every 3-4 working days
------------------------------------------------------
From: Rafael Aquini <aquini@xxxxxxxxxx>
Subject: fs: proc: task_mmu: 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.
This patch introduces 'kernelpagesize_kB' line element to
/proc/<pid>/numa_maps report file in order to help identifying the size of
pages that are backing memory areas mapped by a given task. This is
specially useful to help differentiating between HUGE and GIGANTIC page
backed VMAs.
This patch is based on Dave Hansen's proposal and reviewer's follow-ups
taken from the following dicussion threads:
* https://lkml.org/lkml/2011/9/21/454
* https://lkml.org/lkml/2014/12/20/66
Signed-off-by: Rafael Aquini <aquini@xxxxxxxxxx>
Cc: Johannes Weiner <hannes@xxxxxxxxxxx>
Cc: Dave Hansen <dave.hansen@xxxxxxxxx>
Cc: David Rientjes <rientjes@xxxxxxxxxx>
Signed-off-by: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
---
fs/proc/task_mmu.c | 2 ++
1 file changed, 2 insertions(+)
diff -puN fs/proc/task_mmu.c~fs-proc-task_mmu-show-page-size-in-proc-pid-numa_maps fs/proc/task_mmu.c
--- a/fs/proc/task_mmu.c~fs-proc-task_mmu-show-page-size-in-proc-pid-numa_maps
+++ a/fs/proc/task_mmu.c
@@ -1548,6 +1548,8 @@ static int show_numa_map(struct seq_file
if (!md->pages)
goto out;
+ seq_printf(m, " kernelpagesize_kB=%lu", vma_kernel_pagesize(vma) >> 10);
+
if (md->anon)
seq_printf(m, " anon=%lu", md->anon);
_
Patches currently in -mm which might be from aquini@xxxxxxxxxx are
fs-proc-task_mmu-show-page-size-in-proc-pid-numa_maps.patch
--
To unsubscribe from this list: send the line "unsubscribe mm-commits" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
