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

   (Sorry for the top quoting). Probably the best implementation of
   gettimeofd= ay() is to have
   a page in the kernel mapped read-only to all the user pr= ocesses. Put
   the kernel's idea of time
   into this page. Then getting the = time becomes a simple read (OK, two
   reads, to make sure that
   no update = has happened in between).
   The TSC can then be used to add the precis= ion between the ticks of
   the kernel timer:
   i.e. remember the value of TS= C when the last tick happen, and the
   highest rate at which
   TSC may be ti= cking 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= C. TSC is guaranteed to have
   the same value
   on all the processors that s= hare the same system bus. But if the
   machine is built of multiple
   buses = with bridges between them, all bets are off. Each bus may be
   stopped, resta= rted
   and clocked separately. There is no way to tell, on which CPU is th= e
   process currently
   runnning, and it may be rescheduled do a different C= PU right before
   or after the RDTSC
   instruction.
   -SB
   Ma= r 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= d to read the timestamp counter (TSC) from the processor,
     and use the
     &g= t;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= s read, that you know that there are other relvant
     functions than gettim= eofday() and that these must provide a
     monotonic timescale when queried = interleaved ?
     Be aware that the TSC may not be, and may not stay syn= chronized
     across multiple cores.
     Further more, the TSC is not con= stant frequency and in particular
     not "known frequency" at all times.
     There are a lot of nasty cases to check, and a nasty interpolation
     = required, which, in my tests some years back, totally negated any
     speedu= p from using the TSC in the first place.
     At the very minimum, you wi= ll have to add a quirk table where
     known good {CPU+MOBO+BIOS} combinatio= ns can be entered, as we
     find them.
     >This will also pave way f= or optionally making the
     >FreeBSD kernel tickless,
     Rubbish. T= imecounters are not even closely associated with the
     tick or ticklessnes= s of the kernel. [1]
     > - The TSC frequency might change on cert= ain processors with
     non-constant
     > TSC rate (because of SpeedStep, = dynamic freq scaling etc.). The
     only way to
     > combat this is that t= he kernel be notified every time the
     processor
     > frequency changes.= Every cpu frequency driver will need to be
     updated to
     > notify the= kernel 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= nowing exactly _when_ and _how_ the cpu
     clock
     changed, is a significant = number of microseconds, plenty of time
     to make strange things happen.
     You will want to study carefully Dave Mills work to tame the alpha
     = chips wandering SAW clocks.
     Poul-Henning
     [1] In my mind, rewo= rking the callout system in the kernel would
     be a much better more neded= and much more worthwhile project.
     --
     Poul-Henning Kamp | = UNIX since Zilog Zeus 3.20
     [3]phk_at_FreeBSD.ORG | TCP= /IP since RFC 956
     FreeBSD committer | BSD since 4.3-tahoe
     N= ever attribute to malice what can adequately be explained by
     incompetence.<= br>_______________________________________________
     [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