Skip site navigation (1)Skip section navigation (2)
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>