lkml.org 
[lkml]   [2008]   [Oct]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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.


\
 
 \ /
  Last update: 2008-10-05 08:03    [W:0.111 / U:0.232 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site