(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.freebsd.dk wrote:
In message <[2]17560ccf0903260551v1f5cba9eu8
7727c0bae7b...@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]...@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-hack...@freebsd.org mailing list
[5]http://lists.freebsd.org/mailman/listinfo/freebsd-hackersTo
unsubscribe, send any mail to "[6]fre
ebsd-hackers-unsubscr...@freebsd.org"
References
1. 3D"mailto:p...@phk.freebsd.dk";
2. file://localhost/tmp/3D 3. 3D"mailto:p...@freebsd.org";
4. 3D"mailto:fre 5. 3D"http://lists.=/
6.
3D"mailto:freebsd-hackers-unsub_______________________________________________
freebsd-curr...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
