/proc/*/status Vm… fields
Jan. 28th, 2012 05:37 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
ewxWhat 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.
(no subject)
Date: 2012-01-28 07:04 pm (UTC)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.
(no subject)
From:Acquisition bargain reduced generics no medicament
Date: 2016-11-29 12:29 pm (UTC)[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