Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 7 Mar 2006 12:11:56 +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:  <20060307101156.GF37572@deviant.kiev.zoral.com.ua>
In-Reply-To: <20060306231556.GB64952@comp.chem.msu.su>
References:  <44077091.3060604@freebsd.org> <80813.1141343429@thrush.ravenbrook.com> <20060306231556.GB64952@comp.chem.msu.su>

next in thread | previous in thread | raw e-mail | index | archive | help

--65ImJOski3p8EhYV
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Tue, Mar 07, 2006 at 02:15:56AM +0300, Yar Tikhiy wrote:
> On Thu, Mar 02, 2006 at 11:50:29PM +0000, Nick Barnes wrote:
> > At 2006-03-02 22:24:17+0000, Nik Clayton writes:
> > > I'm failing to understand how getrusage() works, which is a bit perpl=
exing,
> > > because it doesn't seem like it would be terribly complicated.
> >=20
> > ru_maxrss is the maximum resident set size, not the heap size.
> > malloc(big) doesn't grow the resident set.  Touching the memory you
> > have allocated will grow the resident set.  Try this:
> >=20
> >         getrusage(RUSAGE_SELF, &ru);
> >         printf("%lu\n", ru.ru_maxrss);
> >         p =3D malloc(SIZE);
> >         assert(p)
> >         getrusage(RUSAGE_SELF, &ru);
> >         printf("%lu\n", ru.ru_maxrss);
> >         for (i=3D0; i<SIZE; ++i) {
> >                 p[i] =3D 0;
> >         }
> >         getrusage(RUSAGE_SELF, &ru);
> >         printf("%lu\n", ru.ru_maxrss);
>=20
> Well, there was a call to memset() in the original Nik's program
> while your code just does the same by itself.
>=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? :-)

I think that this is a statclock in work :). Just add some busy loops
before each calls to getrusage like

	for (x =3D 0; x < 0x1000000; x++)
			getpid();

and you would get statisically stable results:

deviant% ./1mb
before: 424, after: 1548
deviant% ./1mb
before: 424, after: 1548

See,
% sysctl kern.clockrate
kern.clockrate: { hz =3D 1000, tick =3D 1000, profhz =3D 666, stathz =3D 13=
3 }

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.


--65ImJOski3p8EhYV
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.1 (FreeBSD)

iD8DBQFEDVxrC3+MBN1Mb4gRAjPMAKDZoYwXN/KK4gS+RRnBs9gBWah5vQCeL9TP
T4FQylINVtISvbzDbumESvE=
=62pi
-----END PGP SIGNATURE-----

--65ImJOski3p8EhYV--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060307101156.GF37572>