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>