From owner-freebsd-stable@FreeBSD.ORG Sat Mar 11 01:26:32 2006 Return-Path: X-Original-To: stable@freebsd.org Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4B94516A44A for ; Sat, 11 Mar 2006 01:26:31 +0000 (GMT) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (comp.chem.msu.su [158.250.32.97]) by mx1.FreeBSD.org (Postfix) with ESMTP id 100EC4F1F9 for ; Fri, 10 Mar 2006 22:50:07 +0000 (GMT) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (localhost [127.0.0.1]) by comp.chem.msu.su (8.13.4/8.13.3) with ESMTP id k2AMnqWg078193; Sat, 11 Mar 2006 01:49:52 +0300 (MSK) (envelope-from yar@comp.chem.msu.su) Received: (from yar@localhost) by comp.chem.msu.su (8.13.4/8.13.3/Submit) id k2AMno9k078192; Sat, 11 Mar 2006 01:49:50 +0300 (MSK) (envelope-from yar) Date: Sat, 11 Mar 2006 01:49:50 +0300 From: Yar Tikhiy To: Kostik Belousov Message-ID: <20060310224950.GC75952@comp.chem.msu.su> 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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060307161259.GG37572@deviant.kiev.zoral.com.ua> User-Agent: Mutt/1.5.9i Cc: stable@freebsd.org Subject: Re: Failing to understand getrusage() X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Mar 2006 01:26:33 -0000 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