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
> > > perplexing,
> > > because it doesn't seem like it would be terribly complicated.
> >
> > 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:
> >
> > getrusage(RUSAGE_SELF, &ru);
> > printf("%lu\n", ru.ru_maxrss);
> > p = malloc(SIZE);
> > assert(p)
> > getrusage(RUSAGE_SELF, &ru);
> > printf("%lu\n", ru.ru_maxrss);
> > for (i=0; i<SIZE; ++i) {
> > p[i] = 0;
> > }
> > getrusage(RUSAGE_SELF, &ru);
> > printf("%lu\n", ru.ru_maxrss);
>
> Well, there was a call to memset() in the original Nik's program
> while your code just does the same by itself.
>
> 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 = 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 = 1000, tick = 1000, profhz = 666, stathz = 133 }
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.
pgpKxJflUdGZG.pgp
Description: PGP signature
