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_at_phk.freebsd.dk wrote: >> In message <[2]17560ccf0903260551v1f5cba9eu8 >> 7727c0bae7baa3_at_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_at_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_at_freebsd.org mailing list >> [5]http://lists.freebsd.org/mailman/listinfo/freebsd-hackersTo >> unsubscribe, send any mail to "[6]fre >> ebsd-hackers-unsubscribe_at_freebsd.org" >> >> References >> >> 1. 3D"mailto:phk_at_phk.freebsd.dk" >> 2. file://localhost/tmp/3D 3. 3D"mailto:phk_at_FreeBSD.ORG" >> 4. 3D"mailto:fre 5. 3D"http://lists.=/ >> 6. >> 3D"mailto:freebsd-hackers-unsub_______________________________________________ >> freebsd-current_at_freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to "freebsd-current-unsubscribe_at_freebsd.org" > > _______________________________________________ > freebsd-current_at_freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe_at_freebsd.org" >Received on Fri Mar 27 2009 - 17:25:14 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:45 UTC