Re: kern/45539: add support for getrusage(2) memory size statistics

["Greg A. Woods" <woods%planix.ca@localhost>]

The following reply was made to PR kern/45539; it has been noted by GNATS.

From: "Greg A. Woods" <woods%planix.ca@localhost>
To: NetBSD GNATS <gnats-bugs%NetBSD.org@localhost>
Cc: 
Subject: Re: kern/45539: add support for getrusage(2) memory size statistics
Date: Sun, 30 Oct 2011 20:53:25 -0700

 --pgp-sign-Multipart_Sun_Oct_30_20:53:25_2011-1
 Content-Type: text/plain; charset=US-ASCII
 Content-Transfer-Encoding: quoted-printable
 
 At Sun, 30 Oct 2011 02:15:06 +0000 (UTC), matthew green 
<mrg%eterna.com.au@localhost>=
  wrote:
 Subject: re: kern/45539: add support for getrusage(2) memory size statistics
 >=20
 >  this is from statclock():
 > =20
 >  > +  * rusage VM stats are expressed in kilobytes * ticks-of-execution.
 > =20
 >  this is the wrong way to get these values.  the +=3D will
 >  accumulate over time, 'hz' times a second, depend on the target.
 >  this is probably why you have wrong values.
 
 As per the comment I left quoted above, this accumulation over time is
 actually what's necessary to meet the specifications.
 
 You'll also see in time(1) that it displays the average memory size per
 tick of execution, not the raw value from getrusage().
 
 (And, after all, the instantaneous values are not representative of the
 usage over the interval being measured -- also the instantaneous values
 are available through ps, etc., though self-reference through sysctl(2)
 could be made a wee bit easier, though maybe kern.proc2 with
 KERN_PROC_PID is good enough)
 
 >  initially, i didn't like the look of this one either.
 >  vm_resident_count() can be expensive (but i don't think it is
 >  on any current netbsd ports) but i'm not sure that pushing the
 >  cost of it anywhere else would help.  eg, pushing it into lwp
 >  switch would end up being more expensive to maintain on a system
 >  with very active but switching lwp's.
 
 Exactly.  With statclock() "normally" running at 1/100'th the rate of
 hardclock() (e.g. on i386) this is the least expensive place for such
 statistics to be gathered.
 
 On the other hand it seems this difference in statclock() vs. timeslice
 rates leads to very poor statistics.  (the subject of my recent post in
 tech-kern)
 
 --=20
                                                Greg A. Woods
                                                Planix, Inc.
 
 <woods%planix.com@localhost>       +1 250 762-7675        
http://www.planix.com/
 
 --pgp-sign-Multipart_Sun_Oct_30_20:53:25_2011-1
 Content-Type: application/pgp-signature
 Content-Transfer-Encoding: 7bit
 
 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v1.4.9 (NetBSD)
 
 iD8DBQBOrhu1Zn1xt3i/9H8RAp2xAJ4xGr3KLqhhd/hhrpuaMKj6A0yMnACg1B8D
 9ufUkTAFqI8tLo99LTWchZU=
 =k09I
 -----END PGP SIGNATURE-----
 
 --pgp-sign-Multipart_Sun_Oct_30_20:53:25_2011-1--