[GSoc] Timeconter Performance Improvements

[Jing Huang]

Hi,

 Thanks for you all sincerely. Under your guidance, I read the
specification of TSC in Intel Manual and learned the hardware feature
of TSC:

Processor families increment the time-stamp counter differently:
   • For Pentium M processors (family [06H], models [09H, 0DH]); for Pentium 4
processors, Intel Xeon processors (family [0FH], models [00H, 01H, or 02H]);
and for P6 family processors: the time-stamp counter increments with every
internal processor clock cycle.

   • For Pentium 4 processors, Intel Xeon processors (family [0FH],
models [03H and
higher]); for Intel Core Solo and Intel Core Duo processors (family [06H], model
[0EH]); for the Intel Xeon processor 5100 series and Intel Core 2 Duo processors
(family [06H], model [0FH]); for Intel Core 2 and Intel Xeon processors (family
[06H], display_model [17H]); for Intel Atom processors (family [06H],
display_model [1CH]): the time-stamp counter increments at a constant rate.

Maybe we would implement gettimeofday as fellows. Firstly, use cpuid
to find the family and models of current CPU. If the CPU support
constant TSC, we look up the shared page and calculate the precise
time in usermode. If the platform has invariant TSCs, and we just
fallback to a syscall. So, I think a single global shared page maybe
proper.


On Sat, Mar 26, 2011 at 10:12 PM, John Baldwin <jhb at freebsd.org> wrote:
> On Saturday, March 26, 2011 08:16:46 am Peter Jeremy wrote:
>> On 2011-Mar-25 08:18:38 -0400, John Baldwin <jhb at freebsd.org> wrote:
>> >For modern Intel CPUs you can just assume that the TSCs are in sync across
>> >packages.  They also have invariant TSC's meaning that the frequency
>> >doesn't change.
>>
>> Synchronised P-state invariant TSCs vastly simplify the problem but
>> not everyone has them.  Should the fallback be more complexity to
>> support per-CPU TSC counts and varying frequencies or a fallback to
>> reading the time via a syscall?
>
> I think we should just fallback to a syscall in that case.  We will also need
> to do that if the TSC is not used as the timecounter (or always duplicate the
> ntp_adjtime() work we do for the current timecounter for the TSC timecounter).
>
> Doing this easy case may give us the most bang for the buck, and it is also a
> good first milestone.  Once that is in place we can decide what the value is
> in extending it to support harder variations.
>
> One thing we do need to think about is if the shared page should just export a
> fixed set of global data, or if it should export routines.  The latter
> approach is more complex, but it makes the ABI boundary between userland and
> the kernel more friendly to future changes.  I believe Linux does the latter
> approach?
>
> --
> John Baldwin
>