Improving the kernel/i386 timecounter performance (GSoC proposal)

[Scott Long]

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.

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"