14 messages in org.freebsd.freebsd-hackersRe: [GSoc] Timeconter Performance Imp...| From | Sent On | Attachments |
|---|---|---|
| Jing Huang | Mar 24, 2011 6:34 am | |
| Peter Jeremy | Mar 25, 2011 1:24 am | |
| John Baldwin | Mar 25, 2011 5:18 am | |
| Peter Jeremy | Mar 26, 2011 5:16 am | |
| Kostik Belousov | Mar 26, 2011 5:59 am | |
| John Baldwin | Mar 26, 2011 7:11 am | |
| Jing Huang | Mar 26, 2011 7:42 am | |
| Kostik Belousov | Mar 26, 2011 7:50 am | |
| Warner Losh | Mar 26, 2011 11:02 am | |
| Julian Elischer | Mar 26, 2011 6:22 pm | |
| Warner Losh | Mar 27, 2011 3:32 pm | |
| Mark Tinguely | Mar 27, 2011 7:22 pm | |
| Julian Elischer | Mar 27, 2011 9:29 pm | |
| Warner Losh | Mar 27, 2011 10:13 pm |
| Subject: | Re: [GSoc] Timeconter Performance Improvements | |
|---|---|---|
| From: | Jing Huang (jing...@gmail.com) | |
| Date: | Mar 26, 2011 7:42:40 am | |
| List: | org.freebsd.freebsd-hackers | |
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 <jh...@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 <jh...@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
_______________________________________________ free...@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "free...@freebsd.org"