Date: Fri, 8 Jun 2012 18:03:42 +1000 (EST) From: Bruce Evans <brde@optusnet.com.au> To: Konstantin Belousov <kostikbel@gmail.com> Cc: freebsd-arch@freebsd.org Subject: Re: Fast gettimeofday(2) and clock_gettime(2) Message-ID: <20120608174919.S1594@besplex.bde.org> In-Reply-To: <20120607091243.GV85127@deviant.kiev.zoral.com.ua> References: <20120606165115.GQ85127@deviant.kiev.zoral.com.ua> <201206061423.53179.jhb@freebsd.org> <20120606205938.GS85127@deviant.kiev.zoral.com.ua> <20120607130029.K1962@besplex.bde.org> <20120607091243.GV85127@deviant.kiev.zoral.com.ua>
index | next in thread | previous in thread | raw e-mail
On Thu, 7 Jun 2012, Konstantin Belousov wrote: > On Thu, Jun 07, 2012 at 01:00:34PM +1000, Bruce Evans wrote: >> >> tc_windup()'s close in succession are bugs, since they cycle the timehands >> faster than they were designed to be. We already have too many of these >> bugs (where tc_setclock() calls tc_windup(). I didn't notice this >> particular problem with it before). Now I will point out that version >> 2 of your patch adds more of these calls, apparently to get changes to >> happen sooner. But in sysctl_kern_timecounter_hardware(), such a call >> was intentionaly left out since it is not needed. Note that tc_tick >> prevents calls to tc_windup() more often than about once per msec if >> hz > 1000. > No, I did not added more tc_windup calls. I added a recalculation > of the shared page content on the timecounter change, which is not > the same as tc_windup() call. This is exactly to handle a disable > of usermode rdtsc use when kernel timecounter hardware changes. Oops. I saw a parameter named tc_windup and didn't look too closely at the event handler for this. Please use a slightly different name. Frequent updates of the shared page may cause the same too-fast cycling as frequent calls to tc_windup(). Are event handlers rate-limited? If not, then someone changing the timecounter hardware from a loop in userland could cause similar problems to a settimeofday() loop. Both are privileged operations so this is not a large problem, but it is a stress test that should pass. >> [jhb wrote] >>> There was apparently another issue with version 2. The bcopy() is not >>> atomic, so potentially libc could read wrong tk_current. I redid >>> the interface to write to the shared page to allow use of real atomics. >> >> Timecounter code is supposed to be lock-free except for some time-domain >> locking. I only see 1 problem with this: where tc_windup() writes the >> generation count and other things without asking for these writes to >> be ordered. In most cases, the time-domain locking prevents problems. > In fact, on x86 the ordering is strong enough that no barriers are needed, > this is why the problem goes unnoticed so far. Only the x86 write ordering is clearly strong enough (see another reply). Brucehome | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20120608174919.S1594>