Date: Tue, 7 Mar 2006 18:12:59 +0200 From: Kostik Belousov <kostikbel@gmail.com> To: Yar Tikhiy <yar@comp.chem.msu.su> Cc: stable@freebsd.org Subject: Re: Failing to understand getrusage() Message-ID: <20060307161259.GG37572@deviant.kiev.zoral.com.ua> In-Reply-To: <20060307150631.GC82066@comp.chem.msu.su> References: <44077091.3060604@freebsd.org> <80813.1141343429@thrush.ravenbrook.com> <20060306231556.GB64952@comp.chem.msu.su> <20060307101156.GF37572@deviant.kiev.zoral.com.ua> <20060307150631.GC82066@comp.chem.msu.su>
next in thread | previous in thread | raw e-mail | index | archive | help
--ahP6B03r4gLOj5uD
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Tue, Mar 07, 2006 at 06:06:31PM +0300, Yar Tikhiy wrote:
> On Tue, Mar 07, 2006 at 12:11:56PM +0200, Kostik Belousov wrote:
> > On Tue, Mar 07, 2006 at 02:15:56AM +0300, Yar Tikhiy wrote:
> > >=20
> > > Personally, I'd like to say a "me too". /me too fails to see why
> > > in a quiet, idle system ru_maxrss is very unpredictable over numerous
> > > runs of the test program, both before and after the malloc+memset.
> > > Filling the memory with a non-zero value doesn't matter. Is it the
> > > Heizenberg daemon at work? :-)
> >=20
> > I think that this is a statclock in work :). Just add some busy loops
> > before each calls to getrusage like
> >=20
> > for (x =3D 0; x < 0x1000000; x++)
> > getpid();
> >=20
> > and you would get statisically stable results:
> >=20
> > deviant% ./1mb
> > before: 424, after: 1548
> > deviant% ./1mb
> > before: 424, after: 1548
> >=20
> > See,
> > % sysctl kern.clockrate
> > kern.clockrate: { hz =3D 1000, tick =3D 1000, profhz =3D 666, stathz =
=3D 133 }
> >=20
> > 133 Hz is very slow on 3GHz machine, and curproc->p_stats->p_ru is
> > updated on statclock tick, see sys/kern/kern_clock.c.
>=20
> This sounds very clear and reasonable. I shouldn't have forgotten
> about the driving role of statclock in collecting all rusage stats,
> including those related to memory consumption.
>=20
It may be desirable to add ru_maxrss sampling at the calcru time too.
Something like this:
Index: sys/kern/kern_resource.c
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
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;
=20
p =3D td->td_proc;
PROC_LOCK(p);
+ vm =3D p->p_vmspace;
+ rss =3D pgtok(vmspace_resident_count(vm));
+ if (rup->ru_maxrss < rss)
+ rup->ru_maxrss =3D rss;
+
switch (who) {
=20
case RUSAGE_SELF:
--ahP6B03r4gLOj5uD
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.1 (FreeBSD)
iD8DBQFEDbEKC3+MBN1Mb4gRAkmPAJ0cs+ZNcIkzZsViA8D4MxfuZAH0WACfYGA8
3EsShR8TXTNvhureNSDkoro=
=n0tE
-----END PGP SIGNATURE-----
--ahP6B03r4gLOj5uD--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060307161259.GG37572>