• Rafael Aquini's avatar
    fs: proc: task_mmu: show page size in /proc/<pid>/numa_maps · 198d1597
    Rafael Aquini authored
    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: default avatarRafael Aquini <aquini@redhat.com>
    Cc: Johannes Weiner <hannes@cmpxchg.org>
    Cc: Dave Hansen <dave.hansen@intel.com>
    Acked-by: default avatarDavid Rientjes <rientjes@google.com>
    Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
    Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
    198d1597
proc.txt 83.9 KB