Date: Tue, 07 Dec 2010 08:11:28 +0800 From: David Xu <davidxu@freebsd.org> To: John Baldwin <jhb@freebsd.org> Cc: freebsd-current@freebsd.org, Steve Kargl <sgk@troutmask.apl.washington.edu> Subject: Re: Process accounting/timing has broken recently Message-ID: <4CFD7BB0.20500@freebsd.org> In-Reply-To: <201012060944.03196.jhb@freebsd.org> References: <20101205231829.GA68156@troutmask.apl.washington.edu> <201012060944.03196.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
John Baldwin wrote: > On Sunday, December 05, 2010 6:18:29 pm Steve Kargl wrote: > >> Sometime in the last 7-10 days, some one made a >> change that has broken process accounting/timing. >> >> laptop:kargl[42] foreach i ( 0 1 2 3 4 5 6 7 8 9 ) >> foreach? time ./testf >> foreach? end >> Max ULP: 0.501607 for x in [-18.000000:88.709999] with dx = 1.067100e-04 >> 69.55 real 38.39 user 30.94 sys >> Max ULP: 0.501607 for x in [-18.000000:88.709999] with dx = 1.067100e-04 >> 68.82 real 40.95 user 27.60 sys >> Max ULP: 0.501607 for x in [-18.000000:88.709999] with dx = 1.067100e-04 >> 69.14 real 38.90 user 30.02 sys >> Max ULP: 0.501607 for x in [-18.000000:88.709999] with dx = 1.067100e-04 >> 68.79 real 40.59 user 27.99 sys >> Max ULP: 0.501607 for x in [-18.000000:88.709999] with dx = 1.067100e-04 >> 68.93 real 39.76 user 28.96 sys >> Max ULP: 0.501607 for x in [-18.000000:88.709999] with dx = 1.067100e-04 >> 68.71 real 41.21 user 27.29 sys >> Max ULP: 0.501607 for x in [-18.000000:88.709999] with dx = 1.067100e-04 >> 69.05 real 39.68 user 29.15 sys >> Max ULP: 0.501607 for x in [-18.000000:88.709999] with dx = 1.067100e-04 >> 68.99 real 39.98 user 28.80 sys >> Max ULP: 0.501607 for x in [-18.000000:88.709999] with dx = 1.067100e-04 >> 69.02 real 39.64 user 29.16 sys >> Max ULP: 0.501607 for x in [-18.000000:88.709999] with dx = 1.067100e-04 >> 69.38 real 37.49 user 31.67 sys >> >> testf is a numerically intensive program that tests the >> accuracy of expf() in a tight loop. User time varies >> by ~3 seconds on my lightly loaded 2 GHz core2 duo processor. >> I'm fairly certain that the code does not suddenly grow/loose >> 6 GFLOP of operations. >> > > The user/sys thing is a hack (and has been). We sample the PC at stathz (~128 > hz) to figure out a user vs sys split and use that to divide up the total > runtime (which actually is fairly accurate). All you need is for the clock > ticks to fire just a bit differently between runs to get a swing in user vs > system time. > > What I would like is to keep separate raw bintime's for user vs system time in > the raw data instead, but that would involve checking the CPU ticker more > often (e.g. twice for each syscall, interrupt, and trap in addition to the > current once per context switch). So far folks seem to be more worried about > the extra overhead rather than the loss of accuracy. > > Adding any instruction into global syscall path should be cautioned, it is worse then before, thinking about a threaded application, a userland thread may have locked a mutex and calls a system call, the overhead added to system call path can directly affect a threaded application's performance now, because the time window the mutex is held is longer than before, I have seen some people likes to fiddle with system call path, it should be cautioned. Regards, David Xu
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4CFD7BB0.20500>