|Anonymous | Login||2019-02-16 05:11 UTC|
|Main | My View | View Issues | Change Log | Docs|
|Viewing Issue Simple Details|
|ID||Category||Severity||Type||Date Submitted||Last Update|
|0001189||[1003.1(2016)/Issue7+TC2] Base Definitions and Headers||Editorial||Enhancement Request||2018-03-28 01:57||2018-03-28 08:30|
|Page Number||(page or range of pages)|
|Line Number||(Line or range of lines)|
|Final Accepted Text|
|Summary||0001189: Add memory resources to rusage|
A fairly common need in applications is to monitor the amount of memory used by it. A quick search in Internet will show many suggestions on how to do this, but non of them are portable, unfortunately (see for instance , just to pick one example).
There are several memory metrics that can be interesting:
- Current total virtual memory of the process.
* Linux: VmSize field in /proc/self/status. 
* FreeBSD: field ki_size in struct kinfo_proc returned by kinfo_getproc 
* macOS: field virtual_size in struct task_basic_info given by task_info() 
* Solaris: field pr_size in struct psinfo under /proc/pid/psinfo 
* AIX: field pr_size in /proc/pid/psinfo 
- Current resident memory of the process.
* Linux: VmRSS field in /proc/self/status. 
* FreeBSD: field ki_rssize in struct kinfo_proc returned by kinfo_getproc 
* macOS: field resident_size in struct task_basic_info given by task_info() 
* Solaris: field pr_rssize in struct psinfo under /proc/pid/psinfo 
* AIX: field pr_rssize in struct psinfo under /proc/pid/psinfo 
- Peak total virtual memory since the start of the process.
* Linux: VmPeak field in /proc/self/status. 
* FreeBSD: ??
* macOS: ??
* Solaris: ??
* AIX: ??
- Peak resident memory since the start of the process.
* Linux: ru_maxrss (in KB) in struct rusage. Also VmHWM field in /proc/self/status.
* FreeBSD: ru_maxrss (in KB) in struct rusage.
* macOS: ru_maxrss (in B) in struct rusage.
* Solaris: ru_maxrss (in pages) in struct rusage. Currently returns 0.
* AIX: ru_maxrss (in KB) in struct rusage.
The proposal is to add fields to struct rusage with the mentioned memory values. The ru_maxrss is already ubiquitous across UNIX implementations but unfortunately the units are not consistent. A unified interface would be indeed welcome. I would then propose to add the following fields:
ru_vmsize: Current total virtual memory of the process.
ru_rsssize: Current resident memory of the process.
ru_vmpeak: Peak total virtual memory since the start of the process.
ru_rsspeak: Peak resident memory since the start of the process.
Those fields could be of type size_t, which is consistent with other functions that deal with memory values, like malloc itself.
I would suggest that the definition of resident set size follows the criteria in , namely, it is the sum of the resident anonymous memory, the file mappings and shared memory. The case of compressed memory (Linux zram, AIX AME, macOS from Mavericks on) is probably a bit tricky. I am inclined to think that these values should correspond to physical RAM after compression, but it can also be entirely left to be defined by the implementation.
 http://man7.org/linux/man-pages/man5/proc.5.html [^]
 https://svnweb.freebsd.org/base/head/sys/sys/user.h?revision=326023&view=markup [^]
 https://miknight.blogspot.de/2005/11/resident-set-size-in-mac-os-x.html [^]
 https://www.unix.com/302397379-post4.html [^]
 https://www.ibm.com/support/knowledgecenter/ssw_aix_71/com.ibm.aix.files/proc.htm [^]
 https://stackoverflow.com/questions/669438/how-to-get-memory-usage-at-run-time-in-c [^]
The following should be added to the <sys/resource.h> and getrusage pages:
The <sys/resource.h> header shall define the rusage structure, which shall include at least the following members:
struct timeval ru_utime User time used.
struct timeval ru_stime System time used.
struct timeval ru_vmsize Current virtual memory size.
struct timeval ru_rssize Current resident memory (including resident file mappings and shared memory).
struct timeval ru_vmpeak Peak of virtual memory size since the start of the process.
struct timeval ru_rsspeak Peak of resident memory size since the start of the process (including resident file mappings and shared memory).
If the value of the who argument is RUSAGE_CHILDREN, the peak memory values defined in struct rusage (ru_vmpeak and ru_rsspeak) correspond to the maximum of the peak values of all the children.
|Tags||No tags attached.|
Which implementation(s) currently implement this proposal?
If there are none, the correct approach would be to take this to
one (or better, many) of them, and suggest it.
If you can show enough potential uses that implementations decide
to implement this, then it may be rational to add it to posix,
otherwise, there really is no point, however useful it might seem
it might be.
First: You are trying to extend a structure and this would cause a binary incompatibility.
Then, the interface getrusage() has been introduced by BSD and neither BSD nor Solaris contain the fields you are proposing.
Finally: BeOS and Haiku just implement the minimal structure members as shown in the current POSIX standard.
If you like to add new fields, I recommend you to check for fields that are at least common to all platforms that have a POSIX certification. But this would result in a completely different list.
If you like to get a list of members that are common to all major platforms (except Haiku), I recommend to have a look at the Bourne Shell manual page:
and check the explanation for the shell variable TIMEFORMAT that currently starts at page 25. The entries "X", "D", "K", "M" refer to the struct members:
long ru_maxrss; /* <unimp> */
long ru_ixrss; /* <unimp> */
long ru_idrss; /* <unimp> */
long ru_isrss; /* <unimp> */
that are set to 0 at least on SVr4 and Solaris.
Your proposal does not refer to any of the existing common struct members.
|2018-03-28 01:57||cquike||New Issue|
|2018-03-28 01:57||cquike||Name||=> Enrique Garcia|
|2018-03-28 01:57||cquike||Section||=> sys/resource.h, getrusage|
|2018-03-28 01:57||cquike||Page Number||=> (page or range of pages)|
|2018-03-28 01:57||cquike||Line Number||=> (Line or range of lines)|
|2018-03-28 02:51||kre||Note Added: 0003941|
|2018-03-28 08:30||joerg||Note Added: 0003945|
|Mantis 1.1.6[^] Copyright © 2000 - 2008 Mantis Group|