getrusage

getrusage

[dca]

The implementation of getrusage(2) appears incomplete in the stock
2.2.10 kernel; it's missing memory statistics e.g. the rss numbers.
(It's also missing I/O statistics, but I assume you don't want to hear
about them.)

Is this an old design decision, or simply an oversight?  If an
oversight, I'd be happy to propose a patch for it.

Dave Anderson
dca@torrent.com
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://humbolt.geo.uu.nl/Linux-MM/

Re: getrusage

[Andi Kleen]

On Mon, Aug 02, 1999 at 11:59:18PM +0200, dca@torrent.com wrote:
> The implementation of getrusage(2) appears incomplete in the stock
> 2.2.10 kernel; it's missing memory statistics e.g. the rss numbers.
> (It's also missing I/O statistics, but I assume you don't want to hear
> about them.)
> 
> Is this an old design decision, or simply an oversight?  If an
> oversight, I'd be happy to propose a patch for it.

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.


-Andi

-- 
This is like TV. I don't like TV.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://humbolt.geo.uu.nl/Linux-MM/

Re: getrusage

[dca]

> 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 majordomo@kvack.org.  For more info on Linux MM,
see: http://humbolt.geo.uu.nl/Linux-MM/

Re: getrusage

[Andi Kleen]

On Tue, Aug 03, 1999 at 04:02:53PM +0200, dca@torrent.com wrote:
> > 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.

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.

> 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

-- 
This is like TV. I don't like TV.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://humbolt.geo.uu.nl/Linux-MM/

Re: getrusage

[grg22]

On Tue, Aug 03, 1999 at 04:02:53PM +0200, dca@torrent.com wrote:
> 
> 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 */

If you do fix this, could you please make all these entries *unsigned*
longs?  We need to convert over to using the full 32 bits to allow for full
usage of the memory.  I believe negative values are disallowed for any of
these resource limits and usages, so this particular change shouldn't break
anything anywhere.

Currently linux tries to allow 3GB of virtual, but we're stuck at 2GB
because the resource limits are signed longs rather than unsigned.
There are several patches submitted to fix this.  Basically all the
longs in include/linux/resource.h should be unsigned; IMHO the definition
of INFINITY there should be ~0UL (the current definition, ~0UL>>1, is what
enforces the limit of max 2GB), but I think some differ in opinion here.

We should also get the libc people to correct the get/setrlimit and
getrusage library calls to support unsigned longs.  (What's the mailing
list for glibc?  I can't seem to locate one specifically for it.)

thanks,
grg.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://humbolt.geo.uu.nl/Linux-MM/

Re: getrusage

[dca]

> You need another [new entry]: a vm id.

I'm missing something here.  Isn't the vmid implicit in the caller's
context?  That is, if I call getrusage, I'm asking about "my" vm
statistics.  /proc and gtop are sources of information about other
contexts.

> 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.

> If you do fix this, could you please make all these entries
> *unsigned* longs?

Taking a hint from Solaris' treatment of getrlimit, how 'bout:

  typedef unsigned long rusage_t;

for the flexibility?

Is there interest in providing max values for the individual kinds of
memory (shared/data/stack) in addition to the overall maxrss?  It's
not what I need, and other implementations don't provide it.  They
don't even provide current values, only useless "integrals".

By the sound of it, I have maybe a week to produce something
acceptable if I want to see it in 2.4.  Is that about right?

-dca
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://humbolt.geo.uu.nl/Linux-MM/