Actually OS X is more similar than that: the shared page also contains functions that can be called by user applications, though their entry points are fixed and they're not in any particular format like elf/mach-o. Userspace implementations of gettimeofday, bcopy etc. are provided in the kernel itself, which is a nice design imo as the specific version to load is chosen by the kernel at boot time depending on processor capabilities. On Fri, Mar 27, 2009 at 11:53 PM, Robert Watson <rwatson_at_freebsd.org> wrote: > > 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. >> > > FWIW, there are some variations in schemes across OS's -- one extreme is > the Linux approach, which actually exports a mini shared library in ELF > format on the shared page, providing implementations of various services > (such as entering system calls), time stuff, etc. Less extreme are the > shared pages offered on Mac OS X, etc. > > 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 - 19:48:43 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:45 UTC