From owner-freebsd-hackers@FreeBSD.ORG Sun Mar 27 22:39:33 2011 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 21378106566B; Sun, 27 Mar 2011 22:39:33 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id C420C8FC14; Sun, 27 Mar 2011 22:39:32 +0000 (UTC) Received: from 63.imp.bsdimp.com (63.imp.bsdimp.com [10.0.0.63] (may be forged)) by harmony.bsdimp.com (8.14.3/8.14.1) with ESMTP id p2RMWoxL076713; Sun, 27 Mar 2011 16:32:50 -0600 (MDT) (envelope-from imp@bsdimp.com) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=windows-1252 From: Warner Losh In-Reply-To: Date: Sun, 27 Mar 2011 16:32:50 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <703A54EA-3C99-4BAF-923B-91B50BFFC748@bsdimp.com> References: <201103250818.38470.jhb@freebsd.org> <20110326121646.GA2367@server.vk2pj.dyndns.org> <201103261012.32884.jhb@freebsd.org> To: Jing Huang X-Mailer: Apple Mail (2.1082) Cc: kostikbel@gmail.com, freebsd-hackers@FreeBSD.org, John Baldwin Subject: Re: [GSoc] Timeconter Performance Improvements X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Mar 2011 22:39:33 -0000 On Mar 26, 2011, at 8:43 AM, Jing Huang wrote: > Hi, >=20 > Thanks for you all sincerely. Under your guidance, I read the > specification of TSC in Intel Manual and learned the hardware feature > of TSC: >=20 > Processor families increment the time-stamp counter differently: > =95 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. >=20 > =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 = 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. >=20 > 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. I think that the userspace portion should be more like: int kernel_time_type) SECTION(shared); struct tsc_goo tsc_time_data SECTION(shared); switch (kernel_time_type) { case 1: /* code to use tsc_time_data to return time */ break; default: /* call the kernel */ } I think we should avoid hard-coding lists of CPU families in userland. = The kernel init routines will decide, based on the CPU type and other = stuff if this optimization can be done. This would allow the kernel to = update to support new CPU types without needing to churn libc. Warner P.S. The SECTION(shared) notation above just means that the variables = are in the shared page. >=20 >=20 > On Sat, Mar 26, 2011 at 10:12 PM, John Baldwin = wrote: >> On Saturday, March 26, 2011 08:16:46 am Peter Jeremy wrote: >>> On 2011-Mar-25 08:18:38 -0400, John Baldwin 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. >>>=20 >>> 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? >>=20 >> 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). >>=20 >> 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. >>=20 >> 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? >>=20 >> -- >> John Baldwin >>=20 > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to = "freebsd-hackers-unsubscribe@freebsd.org" >=20 >=20