On Fri, Mar 27, 2009 at 10:19:35PM +0000, Robert Watson wrote: > > 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. Either way, I suspect we really want a function based interface because then we have a layer of insulation between the kernel and userspace. Without this, we're stuck providing any bits in the shared page forever to support old binaries. -- Brooks > 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" >> >> >> >> > _______________________________________________ > 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"
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:45 UTC