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 _______________________________________________ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"