No, cycle counters do just fine.
 
> >1    gettimeofday = 1000000000
> >2    driver delays 10s
> >3    gettimeofday = 1000000000
> >4    timer notices lag and adjusts
> 
> Uh, how is this done?  At this time there IS correction for delays up 
> to about a second built into the gettimeofday() code.  You seem to be 
> assuming that we can do better than this with clock monotonic.  Given 
> the right hardware, this may even be possible, but why not correct 
> gettimeofday in the same way?
	monotonic_clock as proposed uses a hardware clock.
Specifically, the TSC on vanilla intel, the Cyclone timer on x440, and
associated clocks on S/390 (to speak of platforms I've visited
recently).  Right now, the hangcheck-timer accesses the hardware counter
directly.  monotonic_clock is intended as a portable and consistent
accessor instead.
	The current gettimeofday() corrects for ~1s.  Even if we found a
way to correct for ~1000s or more, there would still be a race between
when the caller reads and when the correction happens.  A clock that
reads a hardware counter doesn't have this problem.
	If code doesn't need this accuracy, it can just use
gettimeofday().
Joel
--"Glory is fleeting, but obscurity is forever." - Napoleon Bonaparte
Joel Becker Senior Member of Technical Staff Oracle Corporation E-mail: joel.becker@oracle.com Phone: (650) 506-8127 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/