From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 25 10:50:32 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 9CE6E1065673 for ; Fri, 25 Mar 2011 10:50:32 +0000 (UTC) (envelope-from peterjeremy@acm.org) Received: from fallbackmx07.syd.optusnet.com.au (fallbackmx07.syd.optusnet.com.au [211.29.132.9]) by mx1.freebsd.org (Postfix) with ESMTP id 2394C8FC14 for ; Fri, 25 Mar 2011 10:50:31 +0000 (UTC) Received: from mail35.syd.optusnet.com.au (mail35.syd.optusnet.com.au [211.29.133.51]) by fallbackmx07.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id p2P8OW7h019756 for ; Fri, 25 Mar 2011 19:24:32 +1100 Received: from server.vk2pj.dyndns.org (c220-239-116-103.belrs4.nsw.optusnet.com.au [220.239.116.103]) by mail35.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id p2P8OSTW021801 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 25 Mar 2011 19:24:29 +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.4/8.14.4) with ESMTP id p2P8ORgB056455; Fri, 25 Mar 2011 19:24:27 +1100 (EST) (envelope-from peter@server.vk2pj.dyndns.org) Received: (from peter@localhost) by server.vk2pj.dyndns.org (8.14.4/8.14.4/Submit) id p2P8OR7n056454; Fri, 25 Mar 2011 19:24:27 +1100 (EST) (envelope-from peter) Date: Fri, 25 Mar 2011 19:24:27 +1100 From: Peter Jeremy To: Jing Huang Message-ID: <20110325082427.GA56170@server.vk2pj.dyndns.org> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="PEIAKu/WMn1b1Hv9" Content-Disposition: inline In-Reply-To: X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.21 (2010-09-15) Cc: 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: Fri, 25 Mar 2011 10:50:32 -0000 --PEIAKu/WMn1b1Hv9 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2011-Mar-24 17:00:02 +0800, Jing Huang wrote: > In this scenario, I plan to use both tsc and shared memory to >calculate precise time in user mode. The shared memory includes >system_time, tsc_system_time and factor_tsc-system_time. This sounds like a reasonable approach to me. Note that once we implement a shared page, there is probably a variety of other information we could usefully place on that page. SunOS 4.x included a page of shared memory per CPU. This was mapped as an array (indexed by CPU number) at one address and the page reflecting the current CPU was additionally mapped at another fixed address. This allowed a process to both refer to data on its CPU as well any CPU on the system. > We also consider the CPU frequency, because tsc counter is >related to it. When kernel changes CPU frequency, the shared memory >should be update subsequently. Two issues with this, particularly on x86 without invariant TSC: - looking up the current CPU frequency may not be a cheap operation - the reported CPU frequency appears to be just an approximate value, rather than the actual TSC frequency. On 2011-Mar-24 21:34:35 +0800, Jing Huang wrote: > As I know, tsc counter is CPU specific. If the process running on >a multi-core platform, we must consider switching problem. The one >way, we can let the kernel to take of this. When switching to another >CPU, the kernel will reset the shared memory according to the new CPU. I'm not sure what the cost of managing this page mapping will be. >The second way, we can use CPUID instruction to get the info of >current CPU, which can be executed in user mode ether. At the same >time, the kernel maintains shared memory for each CPU. When invoke >gettimeofday, the function will calculate precise time with current >CPU's shared memory. This approach suffers from a race condition between the CPUID instruction and accessing the appropriate shared page - there is the potential for an interrupt causing the process to be switched to a different CPU, resulting in an incorrect page being accessed. --=20 Peter Jeremy --PEIAKu/WMn1b1Hv9 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (FreeBSD) iEYEARECAAYFAk2MUTsACgkQ/opHv/APuIeKAwCfSWSPl5kfMdsUC4D1gjM2cI0w V0sAoJ7JccSKE4nR/t9s+Jl2wYECdZr0 =SC5O -----END PGP SIGNATURE----- --PEIAKu/WMn1b1Hv9--