From owner-freebsd-hackers@FreeBSD.ORG Sat Mar 26 14:43:04 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 B1709106566B for ; Sat, 26 Mar 2011 14:43:04 +0000 (UTC) (envelope-from jing.huang.pku@gmail.com) Received: from mail-qy0-f175.google.com (mail-qy0-f175.google.com [209.85.216.175]) by mx1.freebsd.org (Postfix) with ESMTP id 500788FC08 for ; Sat, 26 Mar 2011 14:43:03 +0000 (UTC) Received: by qyk35 with SMTP id 35so253103qyk.13 for ; Sat, 26 Mar 2011 07:43:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=ASNbEmPP+JE/X3fpIGBYW/ByjJQldTd8CB8n/83t+7U=; b=NHGey5fmtUUAg11zssv1Zn5ZvNRC6dy4RJX0eFxJz8xzsmLYKDcDZXIZ0/9LfaFBXq QZ77eyU6K8Vm0hpdOwHSjjpTqd/KGWERSzrmIBscGGupGePC3zk42ydrjXccShIVG+1A vbOe1erX1O3JNs3rrtDbqlmT5dGXUE1cwV4ak= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=XN43/obJiaLMDtb2Xshe/czjc+rYnfe6T0ayGsOyOqUO53aXsczabEpGxCbOh4JSUF k+WUsmCJC/rbeHd8XDDALcGWR7J6FuajSIiyPVoGBcqKGMVBfRXMv20Ff+zLpjXeBLAK D6NqgqMWtrRIqJp/IdMn6Gl6CrEbt3IIUO+Vc= MIME-Version: 1.0 Received: by 10.229.141.129 with SMTP id m1mr1688753qcu.52.1301150583554; Sat, 26 Mar 2011 07:43:03 -0700 (PDT) Received: by 10.229.100.132 with HTTP; Sat, 26 Mar 2011 07:43:03 -0700 (PDT) In-Reply-To: <201103261012.32884.jhb@freebsd.org> References: <201103250818.38470.jhb@freebsd.org> <20110326121646.GA2367@server.vk2pj.dyndns.org> <201103261012.32884.jhb@freebsd.org> Date: Sat, 26 Mar 2011 22:43:03 +0800 Message-ID: From: Jing Huang To: John Baldwin Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: kostikbel@gmail.com, freebsd-hackers@freebsd.org 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: Sat, 26 Mar 2011 14:43:04 -0000 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 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 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 >