ewx | /proc/*/status Vm… fields

What do the Vm… entries in /proc/${pid}/status mean?

$ grep ^Vm /proc/$$/status
VmPeak:	   23600 kB
VmSize:	   23536 kB
VmLck:	       0 kB
VmHWM:	    6136 kB
VmRSS:	    2996 kB
VmData:	    4368 kB
VmStk:	     136 kB
VmExe:	     868 kB
VmLib:	    1964 kB
VmPTE:	      64 kB
VmSwap:	    2784 kB

The kernel’s proc.txt has the following to say:

 VmPeak                      peak virtual memory size
 VmSize                      total program size
 VmLck                       locked memory size
 VmHWM                       peak resident set size ("high water mark")
 VmRSS                       size of memory portions
 VmData                      size of data, stack, and text segments
 VmStk                       size of data, stack, and text segments
 VmExe                       size of text segment
 VmLib                       size of shared library code
 VmPTE                       size of page table entries
 VmSwap                      size of swap usage (the number of referred swapents)

man 5 proc is essentially similar.

For the purposes of nps I wanted to know more, so I’ve been poking around in kernel sources and experimenting. These are my conclusions so far.

VmPeak and VmSize are the peak/current total address space used. In other words, the sum of all virtual memory areas in the process, whatever they are used for. (See the caveats below regarding interpretation of this figure.)
VmLck means pages locked into RAM with mlock(). They cannot be swapped, but may be moved to a different location in (physical) RAM.
VmPin is a recent addition (kernel 3.2). Pinned pages are also unswappable, but unlike locked pages their physical address is fixed too.
VmHWM and VmRSS are the process’s peak/current usage of physical RAM.
VmData is calculated as the total address space usage (i.e. VmSize) with shared and stack pages subtracted. This seems rather arbitrary (especially considering the caveat about VmSize below).
VmStk is the size of the stack of the initial thread in the process. This is true even in /proc/${pid}/task/${thread}/status - the stacks for other threads are not distinguished from any other kind of page.
VmExe is equivalent to the difference between endcode and startcode fields from /proc/${pid}/stat. The documentation describes these as bounding the address range in which program text can run; but this seems to be incorrect, based on both inspection and a little test program. Rather they seem to be the bounds of the text section of the initial executable, making VmExe the size of that text section. It does not include shared libraries, JIT compiler output, etc.
VmLib counts executable pages with a VmExe subtracted. The intent must be to measure the quantity of shared library/plugin code in the process, but presumably it’ll include code generated by JIT compilers too.
VmPTE seems to be the amount of kernel memory occupied by page table entries, though being 100% certain about that requires more familiarity with the mm directory than I can claim.
VmSwap is the total swap space used. That will MAP_ANONYMOUS pages that have been swapped out, and dirtied pages from memory-mapped files (for instance executables and shared libraries) but won’t include the text (code) sections of executables. It’s another relatively recent addition, appearing in kernel 2.6.34.

There are some caveats.

VmSize includes pages with PROT_NONE protection (i.e. which allow none of read, execute or write). These don’t consume any RAM or swap, just address space, so this figure can be very inaccurate if used as an estimate for anything other than address space. For instance on amd64 the runtime linker will add 2MB per shared library. The Boehm GC also uses this feature to reserve address space, making the figure to some extent a peak-usage figure rather than a current one.

The figure is nevertheless of some interest, at least on a 32 bit machine: if your process requires more address space than your CPU can provide, you’re stuck - no amount of additional RAM or swap will help and you must recompile your program on a 64-bit machine. On 64-bit systems the limit is a lot further away and, at least currently, the chances are you’re going to run out of something else long before this becomes an issue.
With the exception of VmPTE, these figures all count pages shared with other processes. In some cases that doesn’t matter much; it’s academic for VmSize for instance. In other cases such as VmStk the amount of sharing will usually, but not always, be 0. In other cases it can lead to a overestimation of resource consumption; for instance, if you add up the VmRSS of two processes you’ll double-count the contribution of Glibc.
VmRss includes read-only pages from shared libraries and the executable. While this is certainly useful when calculating the working set of the process, it’s irrelevant if you’re trying to size total RAM and swap, since they needn’t be written to swap: they can be swapped back in from the file they originally came form.

These values are used in nps in the following ways:

`/proc` field	Property	Notes
`VmSize`	`vsz`	`/proc/${pid}/stat` may be used instead
`VmPeak`	`vszpk`
`VmLck`	`locked`
`VmHWM`	`rsspk`
`VmRSS`	`rss`	`/proc/${pid}/stat` may be used instead
`VmData`		Not available
`VmStk`	`stack`
`VmExe`		Not available
`VmLib`		Not available
`VmPTE`	pte
`VmSwap`	`swap`	`/proc/${pid}/smaps` may be used instead

VmData, VmExe and VmLib are omitted because they don’t really mean anything useful.

Flat | Top-Level Comments Only

Might any or all of those (especially the seemingly useless ones) might have other meanings on other architectures?

In multi-threaded programs on 64-bit platforms, VmSize will also be misleadingly gigantic because thread stacks are very big, relying on the memory not really being allocated until used, and depending on overcommit to stop the system running out of virtual memory.

I don’t recall coming across much that was architecture-dependent in my travels, my somewhat superficial impression is of a good portability job. The reporting is completely different on no-MMU platforms so there’s no scope for confusion there.

VmExe could in principle be binary-format-dependent (since that’s where startcode/endcode are filled in) but I think it would be a bug if it was; to the extent that it means anything it means that your executable is that big. The reason I say it’s meaningless is that you could just look at the executable; it’s not like it changes.

I suppose the points about JIT compilers adding to some of the figures is false on platforms too obscure for anyone to have ported their JIT to them l-)

Good point about thread stacks inflating vsize, and one I should have thought of as I’ve had a correspondent be confused by it in the past.

cialis trackback kommentera
[url=http://pharmshop-online.com]generic cialis[/url] cialis for women contraindication
generic cialis (http://pharmshop-online.com) - http:mtg.ornl.govmembersnereeebuycialisgeneric.htmluy cialis generica
cialis and alcohol consumption joined

/proc/*/status Vm… fields

no subject

no subject

Acquisition bargain reduced generics no medicament