Date: Mon, 28 Nov 2005 00:10:37 +1100 (EST) From: Bruce Evans <bde@zeta.org.au> To: Robert Watson <rwatson@FreeBSD.org> Cc: cvs-src@FreeBSD.org, src-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/sys time.h src/sys/kern kern_time.c Message-ID: <20051127234937.X28222@delplex.bde.org> In-Reply-To: <20051127005622.H81764@fledge.watson.org> References: <200511270055.jAR0tIkF032480@repoman.freebsd.org> <20051127005622.H81764@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 27 Nov 2005, Robert Watson wrote: > ... Attached is a small LD_PRELOAD library to > allow applications to be switched to the _FAST variants for gettimeofday(). % /* % * Small wrapper library to substitute implementations of gettimeofday(2) and % * time(3) with lower resolution variations. time(3) is unconditionally % * degraded, since it will return a truncated time anyway. gettimeofday(3) % * checks the TIMEWRAPPER environmental variable, which can be set to either % * "PRECISE" or "FAST". % */ time(3) should use the environment variable too, since the fast version gives a value that is both imprecise and wrong. It inherits bugs from the kernel's time_second variable. time_second is not the current time truncated, but is the (current time less up to about tc_tick/HZ) truncated. It lags the current time by more than 1 second for up to about tc_tick/HZ seconds before every rollover of the correct truncated time. When HZ was 100 it was very easy for applications to see time_second being wring since the average size of the window of incoherency was 1/200 second. time_second is visible in file times by default for ffs file times. The bug can be fixed for ffs too globally using the vfs.timestamp_precision sysctl. I only use this sysctl for running POSIX tests for this bug, but would be surprised if always using it caused noticeable pessimization. Updates of file timestamps are cached in non-broken file systems, so it is hard for them to occur as often as ones for context switches -- they will usually be limited by physical disk write bandwidth. Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20051127234937.X28222>