Re: Fine-grained locking for POSIX local sockets (UNIX domain sockets)

Peter Jeremy wrote:
On Wed, 2006-May-10 10:42:39 +0200, Suleiman Souhlal wrote:

That's not enough. On some CPUs (like the current Opterons), the TSC slows down when the CPU executes a HLT instruction, so if you want good accuracy, you'll need to take that into account too.


The CPU can't be executing any instructions whilst it's halted. All
you need to do is update the base time/TSC count between when you exit
halt and when you return to userland.

Since most sane code doesn't call gettimeofday() multiple times per
tick, one option might be to unmap the page when the base data becomes
invalid and update/remap the page when it is first accessed.


Another way would be to catch the first rdtsc call after a HLT, and reset the TSC to a good value. You can do this by making rdtsc usable only in ring0, which will make any userland rdtsc generate a general protection fault. You have to be careful, though, because on some Intel CPUs, you can only change the lower 32 bits of the TSC (the upper 32 bits get reset to 0 every time you write to the TSC).

We actually implemented this at work, on Linux, to make sure that the TSCs between every processor is synchronized, and it appears to work pretty well.

-- Suleiman

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

Relevant Pages

  • Re: Fine-grained locking for POSIX local sockets (UNIX domain sockets)
    ... slows down when the CPU executes a HLT instruction, so if you want good accuracy, you'll need to take that into account too. ... The CPU can't be executing any instructions whilst it's halted. ... You have to be careful, though, because on some Intel CPUs, you can only change the lower 32 bits of the TSC. ...
    (freebsd-current)
  • RE: [patch 1/] timers: tsc using for cpu scheduling
    ... cpu to brother which wait mutex unlock and will do the same. ... the number of cpu clocks spent for considered task/thread for priority ... It is not need to modify TSC tick rate for cpu scheduling. ... Linux will use TSC for CPU scheduler priority calculatin. ...
    (Linux-Kernel)
  • Re: CONFIG_SLOW_TIMESTAMPS was Re: ANNOUNCE: CE Linux Forum - Specification V1.0 draft
    ... > The obvious way to implement timestamp_t is just store the CPU integrated ... adequate features to support this properly. ... You acknowledge that newer TSC implementations (and things like ... In the case of instrumentation code, ...
    (Linux-Kernel)
  • Re: [PATCH] Add an offset in the cyc2ns computation to fix sched_clock jumps
    ... synchronized TSC. ... takes too long to access and is not enabled before the scheduler. ... - Takes about 225 cycles per TSC read instead of 181. ... Can get a much better time precision by sending an IPI to each CPU ...
    (Linux-Kernel)
  • RE: [patch 1/] timers: tsc using for cpu scheduling
    ... > cpu to brother which wait mutex unlock and will do the same. ... I'm just asking if using the TSC ... I'm not a scheduler guy, so forgive my ignorance, but since the TSC may ... That's fine if its what you propose, I just didn't see it in your patch. ...
    (Linux-Kernel)