Re: Improving the kernel/i386 timecounter performance (GSoC proposal)

From: Prashant Vaibhav <prashant.vaibhav_at_gmail.com>
Date: Sat, 28 Mar 2009 02:18:42 +0530
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