On Tue, 15 Jan 2002, Mike Mason wrote:
> One of the things that libgtop wants for each task is a table of the
> task's memory maps. I can get this from /proc/<pid>/maps. Here's an
> example of the maps from a task on my system. The list for most tasks
> is longer than this one.
>
> 8048000-080ad000 r-xp 00000000 03:02 1240437 /sbin/dhcpcd
> 080ad000-080b0000 rw-p 00064000 03:02 1240437 /sbin/dhcpcd
> 080b0000-080b5000 rwxp 00000000 00:00 0
> 40011000-4001a000 r-xp 00000000 03:02 65339 /lib/libnss_files-2.2.4.so
> 4001a000-4001c000 rw-p 00008000 03:02 65339 /lib/libnss_files-2.2.4.so
> 4001c000-40148000 r-xp 00000000 03:02 65314 /lib/libc-2.2.4.so
> 40148000-4014d000 rw-p 0012b000 03:02 65314 /lib/libc-2.2.4.so
> 4014d000-40151000 rw-p 00000000 00:00 0
> 40151000-40166000 r-xp 00000000 03:02 65297 /lib/ld-2.2.4.so
> 40166000-40167000 rw-p 00014000 03:02 65297 /lib/ld-2.2.4.so
> bfffd000-c0000000 rwxp ffffe000 00:00 0
>
> PCP doesn't provide task memory maps right now. About the only way I
> can see to represent this within the PCP namespace is too include the
> whole table as a single binary or string metric. Seems a bit kludgy,
> but I don't see any other way to do it.
>
> Any suggestions?
If you really have to, you can export the whole table for each process
- there is no technical reason preventing embedded new lines in metrics
with string values, and the length limit is 2^24 (I think).
How does libgtop use the fields in the table? Most likely it wants to
work out per-process virtual and rss mem usage. In that case, you
could do the sums in PCP, and then export a suitable set of metrics,
e.g. very similar to the following metrics that are exported by PCP
on IRIX :
proc.memory.virtual.txt
[per-process executable text virtual memory usage]
proc.memory.virtual.dat
[per-process initialized data virtual memory usage]
proc.memory.virtual.bss
[per-process uninitialized data and break segment virtual memory usage]
proc.memory.virtual.stack
[per-process stack segment virtual memory usage]
proc.memory.virtual.shm
[per-process shared-memory segment virtual memory usage]
proc.memory.physical.txt
[per-process executable text physical memory usage]
proc.memory.physical.dat
[per-process initialized data physical memory usage]
proc.memory.physical.bss
[per-process uninitialized data and break segment physical memory usage]
proc.memory.physical.stack
[per-process stack segment physical memory usage]
proc.memory.physical.shm
[per-process shared-memory segment physical memory usage]
With a suitable heuristic you can tell the mapping type (e.g. bss, txt, dat,
etc) from the mode. The virtual size can be inferred from the high-low
addresss of the mappings and the physical size can be inferred from
the resident page count. Unfortunately there doesn't seem to be any
refcnt field that would allow you to determine pro-rata rss (i.e.
the real rss after accounting for sharing).
> BTW -- would you prefer that I post this type of question to the mailing
> list or email you directly? Also, should I communicate primarily with
> just one of you? If so, who should that be?
This is open source so posting to the pcp@oss list is fine.
thanks
-- Mark
|