Because I was just digging around in the kernel source to determine
this (it's a long story), here is some notes about what the fields
smaps file mean and how they're calculated. The factory
for this particular sausage is fs/proc/task_mmu.c (at least
as of the current git tree).
For each VMA mapping that gets listed in
smaps, the kernel walks all
of the PTEs associated with it and looks at all of the known pages. Each
PTE is then counted up:
- the full PTE size is counted as Rss.
- if the page has been used recently, it's added to Referenced.
- if the page is mapped in only one process it is labeled as private;
its full size is added to Pss.
- if the page is mapped in more than one process it is shared and
the amount it adds to Pss is divided by the number of processes
that have it mapped.
(If the PTE is for something in swap it only adds to the Swap
Note that a 'private' page is not quite as private as you might think.
Because processes map pages independently of each other, it's possible
to have a shared page that is currently mapped only by a single process
(eg only one process may have called an obscure libc function recently);
such pages are counted in 'private'.
The Size of a mapping is how much address space it covers.
If the mapping has been locked into memory via
mlock() or the like,
Locked is the same as Pss (ie, it is this process's fair share of the
amount of locked memory for this mapping); otherwise it is 0 kB.
Given that looking at
smaps requires walking the pages of all of the
VMAs, I suspect that it's a reasonably costly operation. It'd probably
be a bad idea to build a tool that did it a lot, especially if the tool
scanned all processes in the system.
smaps, but it doesn't
normally run repeatedly in the way that, say,