Re: [PATCH v5 1/2] mm: hugetlb: proc: add HugetlbPages field to /proc/PID/smaps

David Rientjes
2015-09-09T22:14:09Z

On Wed, 9 Sep 2015, Vlastimil Babka wrote:

> On 08/20/2015 10:26 AM, Naoya Horiguchi wrote:
> > Currently /proc/PID/smaps provides no usage info for vma(VM_HUGETLB), which
> > is inconvenient when we want to know per-task or per-vma base hugetlb usage.
> > To solve this, this patch adds a new line for hugetlb usage like below:
> >
> > Size: 20480 kB
> > Rss: 0 kB
> > Pss: 0 kB
> > Shared_Clean: 0 kB
> > Shared_Dirty: 0 kB
> > Private_Clean: 0 kB
> > Private_Dirty: 0 kB
> > Referenced: 0 kB
> > Anonymous: 0 kB
> > AnonHugePages: 0 kB
> > HugetlbPages: 18432 kB
> > Swap: 0 kB
> > KernelPageSize: 2048 kB
> > MMUPageSize: 2048 kB
> > Locked: 0 kB
> > VmFlags: rd wr mr mw me de ht
> >
> > Signed-off-by: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
> > Acked-by: Joern Engel <joern@logfs.org>
> > Acked-by: David Rientjes <rientjes@google.com>
>
> Sorry for coming late to this thread. It's a nice improvement, but I find it
> somewhat illogical that the per-process stats (status) are more detailed than
> the per-mapping stats (smaps) with respect to the size breakdown. I would
> expect it to be the other way around. That would simplify the per-process
> accounting (I realize this has been a hot topic already), and allow those who
> really care to look at smaps.
>

Smaps shows the pagesize for the hugepage of the vma and the rss, I
believe you have all the information needed. Some distributions also
change smaps to only be readable by the owner or root for security
reasons.