Messages in this thread | | | Date | Sun, 5 Oct 2008 15:00:49 +0900 | From | "KOSAKI Motohiro" <> | Subject | Re: [PATCH 2/2] Report the pagesize backing a VMA in /proc/pid/maps |
| |
Hi
>> This patch adds a new field for hugepage-backed memory regions to show the >> pagesize in /proc/pid/maps. While the information is available in smaps, >> maps is more human-readable and does not incur the cost of calculating Pss. An >> example of a /proc/self/maps output for an application using hugepages with >> this patch applied is; >> >> 08048000-0804c000 r-xp 00000000 03:01 49135 /bin/cat >> 0804c000-0804d000 rw-p 00003000 03:01 49135 /bin/cat >> 08400000-08800000 rw-p 00000000 00:10 4055 /mnt/libhugetlbfs.tmp.QzPPTJ (deleted) (hpagesize=4096kB) > >> To be predictable for parsers, the patch adds the notion of reporting on VMA >> attributes by appending one or more fields that look like "(attribute)". This >> already happens when a file is deleted and the user sees (deleted) after the >> filename. The expectation is that existing parsers will not break as those >> that read the filename should be reading forward after the inode number >> and stopping when it sees something that is not part of the filename. >> Parsers that assume everything after / is a filename will get confused by >> (hpagesize=XkB) but are already broken due to (deleted). > > Looks like procps will start showing hpagesize tag as a mapping name > (apologies for pasting crappy code):
Administrator expect mapping name is just file name when vma is hugepage via mmap. So, I feel Mel's code is nicer.
Thanks.
| |