NetBSD-Bugs archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

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

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

From: "Greg A. Woods" <>
Subject: Re: kern/45539: add support for getrusage(2) memory size statistics
Date: Sun, 30 Oct 2011 20:53:25 -0700

 Content-Type: text/plain; charset=US-ASCII
 Content-Transfer-Encoding: quoted-printable
 At Sun, 30 Oct 2011 02:15:06 +0000 (UTC), matthew green 
 Subject: re: kern/45539: add support for getrusage(2) memory size statistics
 >  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
                                                Greg A. Woods
                                                Planix, Inc.
 <>       +1 250 762-7675
 Content-Type: application/pgp-signature
 Content-Transfer-Encoding: 7bit
 Version: GnuPG v1.4.9 (NetBSD)

Home | Main Index | Thread Index | Old Index