Improving the kernel/i386 timecounter performance (GSoC proposal)

[Poul-Henning Kamp]

In message <17560ccf0903260551v1f5cba9eu87727c0bae7baa3 at mail.gmail.com>, Prasha
nt Vaibhav writes:

>The gettimeofday() function's implementation will then be
>changed to read the timestamp counter (TSC) from the processor, and use the
>reading in conjunction with the timing info exported by the kernel to
>calculate and return the time info in proper format.

I take it as read, that you know that there are other relvant
functions than gettimeofday() and that these must provide a
monotonic timescale when queried interleaved ?

Be aware that the TSC may not be, and may not stay synchronized
across multiple cores.

Further more, the TSC is not constant frequency and in particular
not "known frequency" at all times.

There are a lot of nasty cases to check, and a nasty interpolation
required, which, in my tests some years back, totally negated any
speedup from using the TSC in the first place.

At the very minimum, you will have to add a quirk table where
known good {CPU+MOBO+BIOS} combinations can be entered, as we
find them.

>This will also pave way for optionally making the
>FreeBSD kernel tickless,

Rubbish.  Timecounters are not even closely associated with the
tick or ticklessness of the kernel. [1]

>   - The TSC frequency might change on certain processors with non-constant
>   TSC rate (because of SpeedStep, dynamic freq scaling etc.). The only way to
>   combat this is that the kernel be notified every time the processor
>   frequency changes. Every cpu frequency driver will need to be updated to
>   notify the kernel before and after a cpu freq change. 

That is not good enough, the bios may autonomously change the cpu speed
and the skew from not knowing exactly _when_ and _how_ the cpu clock
changed, is a significant number of microseconds, plenty of time
to make strange things happen.

You will want to study carefully Dave Mills work to tame the alpha
chips wandering SAW clocks.

Poul-Henning

[1] In my mind, reworking the callout system in the kernel would
be a much better more neded and much more worthwhile project.

-- 
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.