getrusage
Quoted 2 lines
How would you count e.g. shared mappings in a single RSS number? I think you need some more fine grained way to report memory use.
I wrote, then cut out a paragraph from my first mail wondering if there was an opportunity to present statistics in a more useful or comprehensible way.
Since the current implementation seems non-functional, there's no compatibility to break. In fact, the trivial "reasonable" change to me would seem to be yanking the unset entries from struct rusage. But we should be able to do better than that.
Here are the relevant entries from struct rusage:
long ru_maxrss; /* maximum resident set size */ long ru_ixrss; /* integral shared memory size */ long ru_idrss; /* integral unshared data size */ long ru_isrss; /* integral unshared stack size */
I'll presume this covers all interesting types of memory that gets mapped into a process's address space. I'm not sure what the use of the integral values are, and they seem more properly the domain of vtimes() as on aix and maybe bsd?. But having access to the current raw (unintegrated) values seems more useful to me. Getting max values for each makes sense too.
Then there's the question of vm statistics (rather than rss) and then faults charged to each class. But that feels like a slippery slope, unless someone has a clean demarcation line.
On an implementation note, keeping around max values costs a small bit of time whenever a new page is added. Is this enough to be an issue?
-dca
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://humbolt.geo.uu.nl/Linux-MM/
Quoted 21 lines · On Tue, Aug 03, 1999 at 04:02:53PM +0200, [email protected] wrote:
Quoted 2 lines
How would you count e.g. shared mappings in a single RSS number? I think you need some more fine grained way to report memory use.
I wrote, then cut out a paragraph from my first mail wondering if there was an opportunity to present statistics in a more useful or comprehensible way.
Since the current implementation seems non-functional, there's no compatibility to break. In fact, the trivial "reasonable" change to me would seem to be yanking the unset entries from struct rusage. But we should be able to do better than that.
Here are the relevant entries from struct rusage:
long ru_maxrss; /* maximum resident set size */ long ru_ixrss; /* integral shared memory size */ long ru_idrss; /* integral unshared data size */ long ru_isrss; /* integral unshared stack size */
Quoted 6 lines
I'll presume this covers all interesting types of memory that gets mapped into a process's address space. I'm not sure what the use of the integral values are, and they seem more properly the domain of
vtimes()as on aix and maybe bsd?. But having access to the current raw (unintegrated) values seems more useful to me. Getting max values for each makes sense too.
You need another one: a vm id. Multiple "processes" can share VM in linux via clone, and you don't want to account that twice (otherwise there are funny results like 50MB StarOffice with 10 threads reported as 500MB of memory in gtop). I think it is important to have an unique identifier to avoid such mistakes.
There is already a patch floating around on l-k that does that, although it reports via a /proc entry per process. Integrating it in rusage would be a nice addition. The possible unique ids are memory address of the kernel mm_struct (ugly, but zero cost), or the pid of the process who created the VM first.
Quoted 2 lines
On an implementation note, keeping around max values costs a small bit of time whenever a new page is added. Is this enough to be an issue?
Max limits are useful, and it is usually left in the noise from the page zeroing anyways.
-Andi
Signature · 5 lines
This is like TV. I don't like TV. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM, see: http://humbolt.geo.uu.nl/Linux-MM/