3 ms·
Sharing doesn't equate with resident, it equates with virtual memory. You can have a process with 1GB of vm, of which 100MB is shared with other processes but
by jbert 17y ago
Sharing doesn't equate with resident, it equates with virtual memory.
You can have a process with 1GB of vm, of which 100MB is shared with other processes but which has only 10MB resident (hmm...am I wrong? are shared pages never evicted from RAM?)
You can use 'exmap' (if it still compiles) to pull per-page statistics from your kernel and apportion the memory cost of a shared page pro-rata to all the processes, look at what is resident and what is not, and get an "Effective Resident" figure for each process. (You can then look at the process breakdown by shared lib, and the shared libs by ELF symbol).
- old-gregg 17y agojbert, you are not wrong, vmem includes everything. But shared libs have a much higher chance to be in the working set simply because multiple processes are using them. I doubt that clib or any of GTK ever get swapped, so it is safe to assume that on most non-starved systems "real" memory consumption = RES-SHR.
- jbert 17y agoI think I am wrong. I now think top's 'SHR' isn't the "total amount of virtual memory shared", it's "amount of RES which is shared". (Hmm...but my test could be conflating "RES" memory with "allocated" VM (memory which is backed by something, be it swap or RAM). So you can indeed substract SHR from RES to get a feel for per-proc RES. (But that 'feel' doesn't tell you how many procs that SHR is shared with, and worse, which ones. If firefox fork()d then all it firefox-specific code pages would contribute to SHR, but you'd really want to account for them in the "firefox application"). (I'd also definitely expect chunks of libc and gtk libs to not be resident, primarily because they're code pages containing only code paths not yet chased on this box. And only one app has used those pages, do you really want to call that 'shared'?)