Timers and timing, was: MySQL Performance 6.0rc1

[Peter Jeremy]

On Fri, 2005-Oct-28 00:35:24 +0200, Poul-Henning Kamp wrote:
>    *	Does threads have to return ordered timestamps ?
>
>		Consider:
>
>		CPU1			CPU2
>
>		gettimeofday(t1)
>					gettimeofday(t2)
>		gettimeofday(t3)
...
>
>		[t1 <= t2 <= t3]

If this reflects kernel threads, unless there's some sort of explicit
synchronization between the two threads, there's no need to guarantee
anything better than t1 <[=] t3.  If the threads are explicitly
synchronised, then we should guarantee t1 <= t2 <= t3.

On Thu, 2005-Oct-27 19:50:45 -0400, Chuck Swiger wrote:
>I believe Darwin keeps the timecounters of the system exposed on a common 
>page mapped via the System framework (their libc+libm), which gets mapped 
>in once by init, and then shared with all of it's children copy-on-write.  
>They are using the PowerPC timebase registers according to a thread on the 
>darwin-kernel list.

SunOS 4.x (I'm not sure about SunOS 5.x) did this as well.  As Poul
pointed out, this is much easier with sane hardware.

FreeBSD already supports a variety of different timecounters with
different levels of accuracy/performance/guarantees.  One problem is
that this is a system-wide knob whereas different applications may
have different requirements.  Whilst it's reasonable for MySQL to
gather performance statistics, it only needs to measure short time
periods and doesn't require extreme accuracy - the TSC would
probably be good enough on a UP system (if there was a quick way
to measure the current TSC tick rate).  I don't think there's
any way on i386 to quickly access a timecounter that returns a
synchronised time across multiple CPUs.

-- 
Peter Jeremy