From owner-freebsd-current@FreeBSD.ORG Fri Mar 27 16:27:29 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B68931065680; Fri, 27 Mar 2009 16:27:29 +0000 (UTC) (envelope-from babkin@verizon.net) Received: from vms173019pub.verizon.net (vms173019pub.verizon.net [206.46.173.19]) by mx1.freebsd.org (Postfix) with ESMTP id 935B48FC2C; Fri, 27 Mar 2009 16:27:29 +0000 (UTC) (envelope-from babkin@verizon.net) Received: from vms070.mailsrvcs.net ([172.18.12.133]) by vms173019.mailsrvcs.net (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPA id <0KH600L0K88ULXSN@vms173019.mailsrvcs.net>; Fri, 27 Mar 2009 10:26:54 -0500 (CDT) Received: from 65.242.108.162 ([65.242.108.162]) by vms070.mailsrvcs.net (Verizon Webmail) with HTTP; Fri, 27 Mar 2009 10:26:54 -0500 (CDT) Date: Fri, 27 Mar 2009 10:26:54 -0500 (CDT) From: Sergey Babkin To: phk@phk.freebsd.dk Message-id: <11609492.9579.1238167614335.JavaMail.root@vms070.mailsrvcs.net> Content-transfer-encoding: quoted-printable X-Originating-IP: [65.242.108.162] X-Mailman-Approved-At: Fri, 27 Mar 2009 16:37:16 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: attilio@freebsd.org, freebsd-hackers@freebsd.org, freebsd-current@freebsd.org, prashant.vaibhav@gmail.com Subject: Re: Re: Improving the kernel/i386 timecounter performance (GSoC proposal) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2009 16:27:30 -0000 (Sorry for the top quoting). Probably the best implementation of gettimeofd= ay() is to have a page in the kernel mapped read-only to all the user pr= ocesses. Put the kernel's idea of time into this page. Then getting the = time becomes a simple read (OK, two reads, to make sure that no update = has happened in between). The TSC can then be used to add the precis= ion between the ticks of the kernel timer: i.e. remember the value of TS= C when the last tick happen, and the highest rate at which TSC may be ti= cking at this CPU, and export in the same page. This would guarantee thatthe time is not moving back. However there are more issues with TS= C. TSC is guaranteed to have the same value on all the processors that s= hare the same system bus. But if the machine is built of multiple buses = with bridges between them, all bets are off. Each bus may be stopped, resta= rted and clocked separately. There is no way to tell, on which CPU is th= e process currently runnning, and it may be rescheduled do a different C= PU right before or after the RDTSC instruction. -SB Ma= r 26, 2009 06:55:04 PM, [1]phk@phk.freebsd.dk wrote: In message <[2]17560ccf0903260551v1f5cba9eu8= 7727c0bae7baa3@mail.gmail.com>, Prasha nt Vaibhav writes: = >The gettimeofday() function's implementation will then be >change= d to read the timestamp counter (TSC) from the processor, and use the &g= t;reading in conjunction with the timing info exported by the kernel to = >calculate and return the time info in proper format. I take it a= s read, that you know that there are other relvant functions than gettim= eofday() and that these must provide a monotonic timescale when queried = interleaved ? Be aware that the TSC may not be, and may not stay syn= chronized across multiple cores. Further more, the TSC is not con= stant frequency and in particular not "known frequency" at all times. There are a lot of nasty cases to check, and a nasty interpolation = required, which, in my tests some years back, totally negated any speedu= p from using the TSC in the first place. At the very minimum, you wi= ll have to add a quirk table where known good {CPU+MOBO+BIOS} combinatio= ns can be entered, as we find them. >This will also pave way f= or optionally making the >FreeBSD kernel tickless, Rubbish. T= imecounters are not even closely associated with the tick or ticklessnes= s of the kernel. [1] > - The TSC frequency might change on cert= ain processors with non-constant > TSC rate (because of SpeedStep, = dynamic freq scaling etc.). The only way to > combat this is that t= he kernel be notified every time the processor > frequency changes.= Every cpu frequency driver will need to be updated to > notify the= kernel before and after a cpu freq change. That is not good enough= , the bios may autonomously change the cpu speed and the skew from not k= nowing exactly _when_ and _how_ the cpu clock changed, is a significant = number of microseconds, plenty of time to make strange things happen. You will want to study carefully Dave Mills work to tame the alpha = chips wandering SAW clocks. Poul-Henning [1] In my mind, rewo= rking the callout system in the kernel would be a much better more neded= and much more worthwhile project. -- Poul-Henning Kamp | = UNIX since Zilog Zeus 3.20 [3]phk@FreeBSD.ORG | TCP= /IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe N= ever attribute to malice what can adequately be explained by incompetence.<= br>_______________________________________________ [4]freebsd-hackers@freebsd.org mailing list [5]http://lists.freebsd.org/mailman/listinfo/freebsd-hackersTo unsubscribe, send any mail to "[6]fre= ebsd-hackers-unsubscribe@freebsd.org" References 1. 3D"mailto:phk@phk.freebsd.dk" 2. file://localhost/tmp/3D= 3. 3D"mailto:phk@FreeBSD.ORG" 4. 3D"mailto:fre= 5. 3D"http://lists.=/ 6. 3D"mailto:freebsd-hackers-unsub=