I don't think the virtual to physical mapping provides as much insight into memory usage as you might think...
My understanding of the way it works in Linux (in the default Intel configuration) is that the 4GB virtual address space is split into 2 areas, the upper 1GB being a direct mapping to the first GB of physical memory, minus a small range of virtual address used as a window to access any physical memory in excess of 1GB (hence the distinction between high and low memory in the kernel). The lower 3GB of virtual address space is available for the currently running process, and is configured according to /proc/<pid>/maps Working out how your physical memory is currently being used seems to involve quite a few kernel data structures. I don't know of any utility that collates it all into anything other than general statistics. It would be an interesting thing to look at if anyone knows of one. Regards, DigbyT On Mon, Jun 09, 2008 at 05:08:06PM -0700, Roman Shaposhnik wrote: > On Mon, 2008-06-09 at 16:45 +0100, Charles Forsyth wrote: > > > than a Cray, but Linux isn't *that* demanding is it? > > > > last week i added 1gb RAM to my previously 512mbyte lenovo (3000 N100) to > > stop > > the linux system from thrashing. all i run directly is firefox and > > drawterm. > > the system was fine at 512mbyte until a few weeks ago (when more updates > > arrived). > > > > i could probably have got by with `only' 256mbyte or 512mbyte more but the > > bigger memory card was hardly more expensive. > > Since we're on the subject of memory hogs: does anybody know a way for > querying Linux or Solaris (or any OS for that matter) of what the > *physical* pages correspond to and how many virtual pages (and in which > processes) they map into. The only utility that comes close is memstat: > http://www.fifi.org/cgi-bin/man2html/usr/share/man/man1/memstat.1.gz > but I don't quite believe its output, since it relies on the second > hand information available from /proc/*/map and a really awkward mapping > process. > > Thanks, > Roman. -- Digby R. S. Tarvin digbyt(at)digbyt.com http://www.digbyt.com
