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

Actually OS X is more similar than that: the shared page also contains
functions that can be called by user applications, though their entry points
are fixed and they're not in any particular format like elf/mach-o.
Userspace implementations of gettimeofday, bcopy etc. are provided in the
kernel itself, which is a nice design imo as the specific version to load is
chosen by the kernel at boot time depending on processor capabilities.



On Fri, Mar 27, 2009 at 11:53 PM, Robert Watson <rwatson@xxxxxxxxxxx> wrote:


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-current@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@xxxxxxxxxxx"

Relevant Pages

  • 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)
  • 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-hackers)
  • Re: [PATCH] Skip tsc synchronization checks if CONSTANT_TSC bit is set.
    ... Hypervisor couldn't as well be fixed. ... However, when running the kernel on virtual cpus, as compared to running on a physical cpus, the timing characteristics are different -- virtual cpus have to time share physical cpus with each other. ... The fast-path TSC calibration code makes assumptions about being able to sample various counters in sequence in a set amount of time that are not true when running virtualized. ...
    (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)
  • 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-hackers)