Date: Tue, 7 Mar 2006 18:06:31 +0300 From: Yar Tikhiy <yar@comp.chem.msu.su> To: Kostik Belousov <kostikbel@gmail.com> Cc: stable@freebsd.org Subject: Re: Failing to understand getrusage() Message-ID: <20060307150631.GC82066@comp.chem.msu.su> In-Reply-To: <20060307101156.GF37572@deviant.kiev.zoral.com.ua> References: <44077091.3060604@freebsd.org> <80813.1141343429@thrush.ravenbrook.com> <20060306231556.GB64952@comp.chem.msu.su> <20060307101156.GF37572@deviant.kiev.zoral.com.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
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:
> >
> > 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.
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.
Thank you for resolving our doubts! :-)
--
Yar
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060307150631.GC82066>