From owner-freebsd-hackers@FreeBSD.ORG Sat Mar 26 18:02:43 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 61BB8106566C; Sat, 26 Mar 2011 18:02:43 +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 058CD8FC0A; Sat, 26 Mar 2011 18:02:42 +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 p2QI2cRD063735; Sat, 26 Mar 2011 12:02:38 -0600 (MDT) (envelope-from imp@bsdimp.com) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <201103261012.32884.jhb@freebsd.org> Date: Sat, 26 Mar 2011 12:02:37 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201103250818.38470.jhb@freebsd.org> <20110326121646.GA2367@server.vk2pj.dyndns.org> <201103261012.32884.jhb@freebsd.org> To: John Baldwin X-Mailer: Apple Mail (2.1082) Cc: freebsd-hackers@FreeBSD.org, Jing Huang 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 18:02:43 -0000 On Mar 26, 2011, at 8:12 AM, 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=20 > to do that if the TSC is not used as the timecounter (or always = duplicate the=20 > ntp_adjtime() work we do for the current timecounter for the TSC = timecounter). Logically, the code should look like: if (can_do_fast_time) do_the_fast_time else call the kernel We can expand what can or can't do the fast time later once we get the = basics working. > Doing this easy case may give us the most bang for the buck, and it is = also a=20 > good first milestone. Once that is in place we can decide what the = value is=20 > in extending it to support harder variations. Agreed. > 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=20= > approach is more complex, but it makes the ABI boundary between = userland and=20 > the kernel more friendly to future changes. I believe Linux does the = latter=20 > approach? There's nothing that says we can't couple this with loading a = cpu-specific shared library, which would also insulate things. Having a single page of both data and code strikes me as unwise. Having = one of each wouldn't be too bad. Warner=