From owner-freebsd-hackers@FreeBSD.ORG Sat Mar 26 14:51:28 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 A9DB6106566C; Sat, 26 Mar 2011 14:51:28 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 3E3E08FC0C; Sat, 26 Mar 2011 14:51:27 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id p2QEpKQ1003717 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 26 Mar 2011 16:51:20 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4) with ESMTP id p2QEpKku060057; Sat, 26 Mar 2011 16:51:20 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id p2QEpKF6060056; Sat, 26 Mar 2011 16:51:20 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 26 Mar 2011 16:51:20 +0200 From: Kostik Belousov To: John Baldwin Message-ID: <20110326145120.GC78089@deviant.kiev.zoral.com.ua> References: <201103250818.38470.jhb@freebsd.org> <20110326121646.GA2367@server.vk2pj.dyndns.org> <201103261012.32884.jhb@freebsd.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="83IWDyxC26lT0edO" Content-Disposition: inline In-Reply-To: <201103261012.32884.jhb@freebsd.org> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-3.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, DNS_FROM_OPENWHOIS autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua 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 14:51:28 -0000 --83IWDyxC26lT0edO Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Mar 26, 2011 at 10:12:32AM -0400, 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 ac= ross > > >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 timecoun= ter). >=20 > Doing this easy case may give us the most bang for the buck, and it is al= so 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. >=20 > 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. 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 lat= ter=20 > approach? Linux uses a so-called vdso, which is linked into the process. I think that the efforts to implement a vdso approximately equal to the efforts required to implement timecounters in the user mode. On the other hand, with vdso we could properly annotate signal trampolines with the unwind info, that is also a big win. --83IWDyxC26lT0edO Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAk2N/WgACgkQC3+MBN1Mb4iLhACgjFUKhs+u3z+ix1npeg90b/SW 5twAmwauqkkhMeWxuTktDGfKps/j86ab =Dn/T -----END PGP SIGNATURE----- --83IWDyxC26lT0edO--