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:
pgpMImMfLdJf7.pgp
Description: PGP signature
