From owner-freebsd-hackers@FreeBSD.ORG Sun Mar 29 18:07:50 2009 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 508BB106566C; Sun, 29 Mar 2009 18:07:50 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from mail15.syd.optusnet.com.au (mail15.syd.optusnet.com.au [211.29.132.196]) by mx1.freebsd.org (Postfix) with ESMTP id D3D108FC08; Sun, 29 Mar 2009 18:07:49 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from server.vk2pj.dyndns.org (c122-106-216-167.belrs3.nsw.optusnet.com.au [122.106.216.167]) by mail15.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id n2TI7kiV007380 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 30 Mar 2009 05:07:47 +1100 X-Bogosity: Ham, spamicity=0.000000 Received: from server.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by server.vk2pj.dyndns.org (8.14.3/8.14.3) with ESMTP id n2TI7knH025279; Mon, 30 Mar 2009 05:07:46 +1100 (EST) (envelope-from peter@server.vk2pj.dyndns.org) Received: (from peter@localhost) by server.vk2pj.dyndns.org (8.14.3/8.14.3/Submit) id n2TI7je1025278; Mon, 30 Mar 2009 05:07:45 +1100 (EST) (envelope-from peter) Date: Mon, 30 Mar 2009 05:07:45 +1100 From: Peter Jeremy To: Alexander Sack Message-ID: <20090329180745.GB38985@server.vk2pj.dyndns.org> References: <49CD0405.1060704@samsco.org> <5739.1238175087@critter.freebsd.dk> <3c0b01820903271119l4161c7b8yf74613b184add487@mail.gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ADZbWkCsHQ7r3kzd" Content-Disposition: inline In-Reply-To: <3c0b01820903271119l4161c7b8yf74613b184add487@mail.gmail.com> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.19 (2009-01-05) Cc: FreeBSD Hackers , Scott Long , freebsd-current@freebsd.org, prashant.vaibhav@gmail.com Subject: Re: Improving the kernel/i386 timecounter performance (GSoC proposal) 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, 29 Mar 2009 18:07:50 -0000 --ADZbWkCsHQ7r3kzd Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2009-Mar-27 14:19:16 -0400, Alexander Sack wrote: >On Fri, Mar 27, 2009 at 1:31 PM, Poul-Henning Kamp wr= ote: >> In message <49CD0405.1060704@samsco.org>, Scott Long writes: >> >>>I've been talking about this for years. =A0All I need is help with the VM >>>magic to create the page on fork. =A0I also want two pages, one global >>>for gettimeofday (and any other global data we can think of) and one >>>per-process for static data like getpid/getgid. gettimeofday is likely to be a mixture of global and per-core data so possibly a 3rd page containing per-core data is warranted. >I'm assuming folks are still in love with the TSC because it still the >cheapest as oppose ACPI-fast or HPET to even contemplate this? That is its major advantage. It might be feasible to export all the data necessary to implement the complete CLOCK_*_FAST family. >Also I thought at least PHK's comment (Sergey mentioned it) was true >regardless of bus, that the TSC is not consistent across multiple >packages (and for that matter I suppose cores) due to I *think* its >ISA lineage so how does this work again? TSC is nothing to do with ISA. The easiest way to build a counter that runs at CPU clock rate is to put it very close to the CPU/core and have different counters for each CPU/core, without any synchronisation between the different counters. > Won't the rate in which you >tick up be sporadic over the course of the process scheduled on >different cores? (i.e. depending on what core RDTSC happened to land >on) RDTSC will wind up on the same core that your thread of execution is running on and this is defined by the scheduler. IE, it's up to the scheduler to ensure that the correct page of global (or per-cpu) data is mapped. --=20 Peter Jeremy --ADZbWkCsHQ7r3kzd Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.10 (FreeBSD) iEYEARECAAYFAknPuPEACgkQ/opHv/APuIdvSQCeNOrRWB5USFabAeGF0x/sFeHg RykAn3f5uD9lFiPLI5BlsXGtDRyiOQGM =Jqic -----END PGP SIGNATURE----- --ADZbWkCsHQ7r3kzd--