Our measurement problem [LWN.net]

Our measurement problem

Posted Aug 4, 2005 5:07 UTC (Thu) by JoeBuck (subscriber, #2330)
In reply to: Our bloat problem by hp
Parent article: Our bloat problem

One of the more embarrassing problems is that we don't really have tools that can give us an accurate picture of the problem. Everyone will tell you that "top" doesn't give an accurate picture, and everyone is right. The difficulty is that there is at present no tool that really shows what is going on.

Before we can really improve things, we need better measurement tools. Remember how much faster the boot times got after some guy did bootchart?

Back in the early 80s, VMS had a "graphical" (termcap-style) tool that would show a real-time animation of every page in memory, tracing it to the corresponding executable or shared library or kernel. The modern extension would show memory-mapped files, cached files, etc. as well. If we could just have those pictures, people's attention would quickly focus on the hot spots.

(Log in to post comments)

Our measurement problem

Posted Aug 4, 2005 7:13 UTC (Thu) by freddyh (subscriber, #21133) [Link]

I do agree that there is not really a tool that *easily* shows the memory problem. Atkins however can teach you exactly what your application is doing, including its memory usage.
Unfortunately you'll have to dig in yourself, and the first time will cost you quite some time.

FreddyH

Our measurement problem

Posted Aug 4, 2005 12:45 UTC (Thu) by MathFox (guest, #6104) [Link]

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?

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 (subscriber, #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.