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

From: Robert Watson <rwatson_at_FreeBSD.org>
Date: Fri, 27 Mar 2009 18:25:14 +0000 (GMT)
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.

One note though -- the time to do the global page is at execve()-time.

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 - 17:25:14 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:45 UTC