Timers and timing, was: MySQL Performance 6.0rc1

[Poul-Henning Kamp]

In message <20051028201505.GV39882 at cirb503493.alcatel.com.au>, Peter Jeremy wri
tes:

>I was thinking that if the cost differential is large enough, it might
>be worthwhile using different hardware counters (especially for duration
>values where you don't have to worry about getting a valid UTC time).

Yes, that is an obvious way to tune things.

The problem however is the same: Getting convinced that the TSC is
constant frequency is non-trivial.

>This would probably mean adding a system call to set a default timer
>type which is part of the struct proc - upon reflection, there would be
>a significant amount of kernel API churn (at least) to get this to work.

And worse: Unless we can sell the concept to the other contemporary
UNIXen, another FreeBSD specific API which sees little use.

>To go off on a different tangent, would it be possible to use the NTP
>algorithms to synchronize the TSC? 

It all comes down to how much CPU time you're willing to burn to make
timekeeping faster...

>This gives something like:
>    now = magic->offset + (rdtsc() * magic->multiplier) >> magic->shift;

You should really read
	http://phk.freebsd.dk/pubs/timecounter.pdf

first :-)

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.