Date: Fri, 27 Mar 2009 10:26:54 -0500 (CDT) From: Sergey Babkin <babkin@verizon.net> To: phk@phk.freebsd.dk Cc: attilio@freebsd.org, freebsd-hackers@freebsd.org, freebsd-current@freebsd.org, prashant.vaibhav@gmail.com Subject: Re: Re: Improving the kernel/i386 timecounter performance (GSoC proposal) Message-ID: <11609492.9579.1238167614335.JavaMail.root@vms070.mailsrvcs.net>
next in thread | raw e-mail | index | archive | help
(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@phk.freebsd.dk wrote:
In message <[2]17560ccf0903260551v1f5cba9eu8=
7727c0bae7baa3@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@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@freebsd.org mailing list
[5]http://lists.freebsd.org/mailman/listinfo/freebsd-hackersTo
unsubscribe, send any mail to "[6]fre=
ebsd-hackers-unsubscribe@freebsd.org"
References
1. 3D"mailto:phk@phk.freebsd.dk"
2. file://localhost/tmp/3D=
3. 3D"mailto:phk@FreeBSD.ORG"
4. 3D"mailto:fre=
5. 3D"http://lists.=/
6. 3D"mailto:freebsd-hackers-unsub=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?11609492.9579.1238167614335.JavaMail.root>