[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" <woods%planix.ca@localhost>
To: NetBSD GNATS <gnats-bugs%NetBSD.org@localhost>
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
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():
> > + * rusage VM stats are expressed in kilobytes * ticks-of-execution.
> 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
<woods%planix.com@localhost> +1 250 762-7675
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (NetBSD)
-----END PGP SIGNATURE-----
Main Index |
Thread Index |