Date: Sat, 26 Mar 2011 22:43:03 +0800 From: Jing Huang <jing.huang.pku@gmail.com> To: John Baldwin <jhb@freebsd.org> Cc: kostikbel@gmail.com, freebsd-hackers@freebsd.org Subject: Re: [GSoc] Timeconter Performance Improvements Message-ID: <AANLkTimjj6dimyoY1K4xKabiNeAMjSt-YXjFpdaTJCTr@mail.gmail.com> In-Reply-To: <201103261012.32884.jhb@freebsd.org> References: <AANLkTimbBohQmoPv19Qq2U6M70OBx%2BFBMiUAzQmqrTLK@mail.gmail.com> <201103250818.38470.jhb@freebsd.org> <20110326121646.GA2367@server.vk2pj.dyndns.org> <201103261012.32884.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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: =95 For Pentium M processors (family [06H], models [09H, 0DH]); for Pent= ium 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. =95 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 proce= ssors (family [06H], model [0FH]); for Intel Core 2 and Intel Xeon processors (fa= mily [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@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@freebsd.org> wrote: >> >For modern Intel CPUs you can just assume that the TSCs are in sync acr= oss >> >packages. =A0They 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. =A0Should 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. =A0We will als= o 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 timecoun= ter). > > Doing this easy case may give us the most bang for the buck, and it is al= so a > good first milestone. =A0Once that is in place we can decide what the val= ue is > in extending it to support harder variations. > > One thing we do need to think about is if the shared page should just exp= ort a > fixed set of global data, or if it should export routines. =A0The latter > approach is more complex, but it makes the ABI boundary between userland = and > the kernel more friendly to future changes. =A0I believe Linux does the l= atter > approach? > > -- > John Baldwin >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?AANLkTimjj6dimyoY1K4xKabiNeAMjSt-YXjFpdaTJCTr>