Our measurement problem

Posted Aug 4, 2005 14:59 UTC (Thu) by Yorick (guest, #19241)
In reply to: Our measurement problem by MathFox
Parent article: Our bloat problem

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.