Messages in this thread | | | Date | Wed, 9 Sep 2015 15:14:05 -0700 (PDT) | From | David Rientjes <> | Subject | Re: [PATCH v5 1/2] mm: hugetlb: proc: add HugetlbPages field to /proc/PID/smaps |
| |
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.
| |