Failing to understand getrusage()

Kostik Belousov kostikbel at gmail.com
Mon Mar 13 10:37:05 UTC 2006


On Sat, Mar 11, 2006 at 01:49:50AM +0300, Yar Tikhiy wrote:
> On Tue, Mar 07, 2006 at 06:12:59PM +0200, Kostik Belousov wrote:
> > 
> > It may be desirable to add ru_maxrss sampling at the calcru time too.
> > Something like this:
> > 
> > Index: sys/kern/kern_resource.c
> > ===================================================================
> > RCS file: /usr/local/arch/ncvs/src/sys/kern/kern_resource.c,v
> > retrieving revision 1.156
> > diff -u -r1.156 kern_resource.c
> > --- sys/kern/kern_resource.c	22 Feb 2006 16:58:48 -0000	1.156
> > +++ sys/kern/kern_resource.c	7 Mar 2006 16:10:27 -0000
> > @@ -853,9 +853,16 @@
> >  	struct rusage *rup;
> >  {
> >  	struct proc *p;
> > +	struct vmspace *vm;
> > +	long rss;
> >  
> >  	p = td->td_proc;
> >  	PROC_LOCK(p);
> > +	vm = p->p_vmspace;
> > +	rss = pgtok(vmspace_resident_count(vm));
> > +	if (rup->ru_maxrss < rss)
> > +		rup->ru_maxrss = rss;
> > +
> >  	switch (who) {
> >  
> >  	case RUSAGE_SELF:
> > 
> 
> Please excuse me for a dumb question, but what makes ru_maxrss so
> different from other ru_ fields that it deserves special handling
> in kern_getrusage()?  Perhaps the all-or-nothing approach will be
> better for the sake of consistency...

Current resource usage accounting is inaccurate (i.e. done at sampling
points) only for several fields, ru_maxrss being one of them. E.g.,
ru_nsignals is precise.

Sure, the best would be implementing approach like solaris microaccounting
(AFAIR, solaris could measure used parts of the time-slice where
the thread runs on CPU, and do this measure on demand, not stressing
the system when the exact numbers are not needed).

My small fix just add little more sence to result of maxrss calculation,
making it to never return meaningless values like 0. Better, pmaps
shall be modified to correctly set maxrss (this seems to be not hard,
could someone look at the patch if I implement it ?).
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20060313/a22d2765/attachment.pgp


More information about the freebsd-stable mailing list