Fast gettimeofday(2) and clock_gettime(2)

[John Baldwin]

On Wednesday, June 06, 2012 9:35:49 pm Bruce Evans wrote:
> On Wed, 6 Jun 2012, John Baldwin wrote:
> 
> > On Wednesday, June 06, 2012 12:51:15 pm Konstantin Belousov wrote:
> >> A positive result from the recent flame-bait on arch@ is the working
> >> implementation of the fast gettimeofday(2) and clock_gettime(2). The
> >> speedup I see is around 6-7x on the 2600K. I think the speedup could
> >> be even bigger on the previous generation of CPUs, where lock
> >> operations and syscall entry are costlier. A sample test runs of
> >> tools/tools/syscall_timing are presented at the end of message.
> >
> > In general this looks good but I see a few nits / races:
> 
> It is awefully (sic) complete and large.  The patch is almost twice as
> large as the entire kern_tc.c in FreeBSD-4, and that was quite bloated.
> 
> > 1) You don't follow the model of clearing tk_current to 0 while you
> >   are updating the structure that the in-kernel timecounter code
> >   uses.  This also means you have to avoid using a tk_current of 0
> >   and that userland has to keep spinning as long as tk_current is 0.
> >   Without this I believe userland can read a partially updated
> >   structure.
> 
> I thought that too at first, but after looking at the patch decided
> that it may be correct, but is too hard for me to understand.
> Urk, we both missed that tk_current is an index into the timehands
> array, so it cannot act as a generation count and it seems to be harder
> to lock.

Ugh, so it goes a long way to emulate the timehands array in userland.  As I 
mentioned previously, I consider the timehands array to be a bug.  However, I 
do think the generation count in the in-kernel timehands structure is useful 
and should be kept (and follow the same model of setting it to 0 before doing
updates, then updating the structure, then setting the new generation).

-- 
John Baldwin