Date: Sat, 11 Mar 2006 01:49:50 +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: <20060310224950.GC75952@comp.chem.msu.su> In-Reply-To: <20060307161259.GG37572@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> <20060307150631.GC82066@comp.chem.msu.su> <20060307161259.GG37572@deviant.kiev.zoral.com.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Mar 07, 2006 at 06:12:59PM +0200, Kostik Belousov wrote:
> 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:
> > > >
> > > > 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.
> >
>
> It may be desirable to add ru_maxrss sampling at the calcru time too.
> Something like this:
>
> Index: sys/kern/kern_resource.c
> ===================================================================
> 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;
>
> p = td->td_proc;
> PROC_LOCK(p);
> + vm = p->p_vmspace;
> + rss = pgtok(vmspace_resident_count(vm));
> + if (rup->ru_maxrss < rss)
> + rup->ru_maxrss = rss;
> +
> switch (who) {
>
> case RUSAGE_SELF:
>
Please excuse me for a dumb question, but what makes ru_maxrss so
different from other ru_ fields that it deserves special handling
in kern_getrusage()? Perhaps the all-or-nothing approach will be
better for the sake of consistency...
--
Yar
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060310224950.GC75952>