On Sat, 28 Mar 2009, Prashant Vaibhav wrote: > 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. One cute thing about Linux exporting the page as ELF is that the dynamic linker just finds and links libc against it for the system call path. ELF is a fairly straight-forward format, so it's not a bad approach, although it does make the kernel side more complex. One downside, of course, is that it means the kernel has to export 32-bit code to 32-bit processes, 64-bit code to 64-bit processes, etc, if you want the higher performance stuff for 32-bit processes on 64-bit kernels, you have to build the exposed code as non-native code. Robert N M Watson Computer Laboratory University of Cambridge > > > > 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 - 21:19:36 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:45 UTC