From owner-freebsd-current@FreeBSD.ORG Fri Mar 27 18:25:14 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 C548F1065722; Fri, 27 Mar 2009 18:25:14 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 88E648FC08; Fri, 27 Mar 2009 18:25:14 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id 4220746B55; Fri, 27 Mar 2009 14:25:14 -0400 (EDT) Date: Fri, 27 Mar 2009 18:25:14 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Scott Long In-Reply-To: <49CD0405.1060704@samsco.org> Message-ID: References: <11609492.9579.1238167614335.JavaMail.root@vms070.mailsrvcs.net> <49CD0405.1060704@samsco.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Sergey Babkin , freebsd-hackers@freebsd.org, attilio@freebsd.org, phk@phk.freebsd.dk, freebsd-current@freebsd.org, prashant.vaibhav@gmail.com Subject: 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 18:25:15 -0000 On Fri, 27 Mar 2009, Scott Long wrote: > I've been talking about this for years. All I need is help with the VM > magic to create the page on fork. I 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. One note though -- the time to do the global page is at execve()-time. Robert N M Watson Computer Laboratory University of Cambridge > > Scott > > > Sergey Babkin wrote: >> (Sorry for the top quoting). Probably the best implementation of >> gettimeofd=y() is to have >> a page in the kernel mapped read-only to all the user pr=cesses. Put >> the kernel's idea of time >> into this page. Then getting the =ime becomes a simple read (OK, two >> reads, to make sure that >> no update =as happened in between). >> The TSC can then be used to add the precis=on between the ticks of >> the kernel timer: >> i.e. remember the value of TS= when the last tick happen, and the >> highest rate at which >> TSC may be ti=king 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=. TSC is guaranteed to have >> the same value >> on all the processors that s=are the same system bus. But if the >> machine is built of multiple >> buses =ith bridges between them, all bets are off. Each bus may be >> stopped, resta=ted >> and clocked separately. There is no way to tell, on which CPU is th= >> process currently >> runnning, and it may be rescheduled do a different C=U right before >> or after the RDTSC >> instruction. >> -SB >> Ma= 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= to read the timestamp counter (TSC) from the processor, >> and use the >> &g=;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= read, that you know that there are other relvant >> functions than gettim=ofday() and that these must provide a >> monotonic timescale when queried =nterleaved ? >> Be aware that the TSC may not be, and may not stay syn=hronized >> across multiple cores. >> Further more, the TSC is not con=tant frequency and in particular >> not "known frequency" at all times. >> There are a lot of nasty cases to check, and a nasty interpolation >> =equired, which, in my tests some years back, totally negated any >> speedu= from using the TSC in the first place. >> At the very minimum, you wi=l have to add a quirk table where >> known good {CPU+MOBO+BIOS} combinatio=s can be entered, as we >> find them. >> >This will also pave way f=r optionally making the >> >FreeBSD kernel tickless, >> Rubbish. T=mecounters are not even closely associated with the >> tick or ticklessnes= of the kernel. [1] >> > - The TSC frequency might change on cert=in processors with >> non-constant >> > TSC rate (because of SpeedStep, =ynamic freq scaling etc.). The >> only way to >> > combat this is that t=e kernel be notified every time the >> processor >> > frequency changes.=very cpu frequency driver will need to be >> updated to >> > notify the=ernel 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=owing exactly _when_ and _how_ the cpu >> clock >> changed, is a significant =umber of microseconds, plenty of time >> to make strange things happen. >> You will want to study carefully Dave Mills work to tame the alpha >> =hips wandering SAW clocks. >> Poul-Henning >> [1] In my mind, rewo=king the callout system in the kernel would >> be a much better more neded=nd much more worthwhile project. >> -- >> Poul-Henning Kamp | =NIX since Zilog Zeus 3.20 >> [3]phk@FreeBSD.ORG | TCP=IP since RFC 956 >> FreeBSD committer | BSD since 4.3-tahoe >> N=ver attribute to malice what can adequately be explained by >> incompetence.<=r>_______________________________________________ >> [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_______________________________________________ >> freebsd-current@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" >