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


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.

FWIW, there are some variations in schemes across OS's -- one extreme is the Linux approach, which actually exports a mini shared library in ELF format on the shared page, providing implementations of various services (such as entering system calls), time stuff, etc. Less extreme are the shared pages offered on Mac OS X, etc.

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@xxxxxxxxxxxxxx wrote:
In message <[2]17560ccf0903260551v1f5cba9eu8 7727c0bae7baa3@xxxxxxxxxxxxxx>, 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@xxxxxxxxxxx | 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@xxxxxxxxxxx mailing list
[5]http://lists.freebsd.org/mailman/listinfo/freebsd-hackersTo
unsubscribe, send any mail to "[6]fre ebsd-hackers-unsubscribe@xxxxxxxxxxx"

References

1. 3D"mailto:phk@xxxxxxxxxxxxxx";
2. file://localhost/tmp/3D 3. 3D"mailto:phk@xxxxxxxxxxx";
4. 3D"mailto:fre 5. 3D"http://lists.=/
6. 3D"mailto:freebsd-hackers-unsub_______________________________________________
freebsd-current@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@xxxxxxxxxxx"

_______________________________________________
freebsd-current@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@xxxxxxxxxxx"

_______________________________________________
freebsd-hackers@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@xxxxxxxxxxx"

Relevant Pages

  • Re: Hyper-Threading Vulnerability
    ... >> The apps that bother to use rdtsc vs. gettimeofday need a cheap high res ... >> provides a reliable time source at all, due to SMP and frequency scaling ... > On x86-64 the cost of gettimeofday is the same of the tsc, ... TSC is something only the kernel (or a ...
    (Linux-Kernel)
  • Re: Improving the kernel/i386 timecounter performance (GSoC proposal)
    ... functions that can be called by user applications, ... chosen by the kernel at boot time depending on processor capabilities. ... TSC may be ti=king at this CPU, and export in the same page. ...
    (freebsd-current)
  • Re: can TSC tick with different speeds on SMP?
    ... Ultimatively the kernel will need to move to a per CPU time base ... > So the question is "is such system compliant with SMP ... The usual way to is to turn off tsc support in gettimeofday. ...
    (Linux-Kernel)
  • Re: nosmp/maxcpus=0 or 1 -> TSC unstable
    ... which would mean cpu_possible_map contains the second cpu... ... not quite sure what the right fix is... ... TSC makes gettimeofday() itself very slow, on the order of 30 us. ...
    (Linux-Kernel)
  • Re: Improving the kernel/i386 timecounter performance (GSoC proposal)
    ... one global for gettimeofday and one per-process for static data like getpid/getgid. ... a page in the kernel mapped read-only to all the user pr=cesses. ... TSC may be ti=king at this CPU, and export in the same page. ...
    (freebsd-current)