Our measurement problem [LWN.net]

Our measurement problem

Posted Aug 4, 2005 12:45 UTC (Thu) by MathFox (guest, #6104)
In reply to: Our measurement problem by JoeBuck
Parent article: Our bloat problem

Well "cat /proc/<pid>/maps" allready gives you a lot of information:

$ cat /proc/self/maps
08048000-0804c000 r-xp 00000000 21:06 32615 /bin/cat
0804c000-0804d000 rw-p 00003000 21:06 32615 /bin/cat
0804d000-0804e000 rwxp 00000000 00:00 0
40000000-40014000 r-xp 00000000 21:06 23031 /lib/ld-2.3.2.so
40014000-40015000 rw-p 00014000 21:06 23031 /lib/ld-2.3.2.so
40027000-40156000 r-xp 00000000 21:06 23037 /lib/libc.so.6
40156000-4015a000 rw-p 0012f000 21:06 23037 /lib/libc.so.6
4015a000-4015e000 rw-p 00000000 00:00 0
4015e000-4035e000 r--p 00000000 21:06 23404 /usr/lib/locale/locale-archive
bfffe000-c0000000 rwxp fffff000 00:00 0

This shows a quite lean program, in order of the lines:
3 pages of application code (potentially sharable)
1 page of initialised data (theoreticly sharable)
1 page of uninitialised data (not sharable)
21 pages for the dynamic loader code (shared)
1 page of dynamic loader initialised data (potentially shared)
303 pages of shared C library code (shared)
4 pages of C library data (may be shared or private)
4 pages with private data
512 pages of shared data (locale-archive)
and finally 2 pages of stack. (unshared)

(each page on this machine is 4 kb)

Most of the apparent bloat for cat (850 pages * 4 k = 3.4 Mb) is in localisation and the shared C library. All but 16 pages (64 k) are shared with other processes.

Who writes a nice graphical frontend to /proc/*/maps?

(Log in to post comments)

Our measurement problem

Posted Aug 4, 2005 14:59 UTC (Thu) by Yorick (subscriber, #19241) [Link]

It is not possible from /proc/$pid/maps to find out how many pages of a mapped file have been
privately modified (.data sections etc). This would be a useful addition, but because of the lack of
forethought it can be difficult to add it to this pseudo-file without breaking existing programs.

It is also not possible to find the set of actually shared pages from a mapped file - just because
two processes both map a common shared object, it does not mean they both use all pages from
it, or that they use the same pages. It is quite common to see entire DSOs being mapped without
being used by the process at all.

We definitely need better memory usage metrics from the kernel, or bloat like this will be difficult
to profile.

Our measurement problem

Posted Aug 6, 2005 14:00 UTC (Sat) by sandmann (guest, #473) [Link]

The kernel actually has a system call - mincore - that tells you which pages of a mapped file are in memory. I wrote a small program a long time ago that uses it to print more details about memory usage:

http://www.daimi.au.dk/~sandmann/freon.c

You have to be root to run it.

Unfortunately a similar thing can't be done for malloc()d memory because mincore doesn't work for anonymous pages.