Fine-grained locking for POSIX local sockets
(UNIX domain sockets)
ssouhlal at FreeBSD.org
Wed May 10 08:43:04 UTC 2006
Paul Allen wrote:
>>From Julian Elischer <julian at elischer.org>, Tue, May 09, 2006 at 10:35:06AM -0700:
>>Sven Petai wrote:
>>are there any patches that take the gettimeofday() calls and replace
>>them with something that is cheap
>>such as only doing every 10th one and just returning the last value ++ 1
>>uSec for the other ones..
> Better yet, just realize that during any given scheduler quantum the process
> is running on the same CPU. Therefore, you should just read the TSC.
> For that matter, if libc would just remember an accurate synchronized
> timestamp and TSC pair on a per CPU basis, it should be trivial to get
> cheap, synchronized, and accurate TSC time on SMP systems. TSC drift
> isn't horrible--and best of all if the process drifts from CPU to CPU
> libc will have a decent chance at doing incremental calibrations. Simply
> giving libc easy access to a counter of scheduler ticks can be used to
> ensure this process delivers monotonic time.
> Let me formalize this a bit, you have a noisy, but cheap time source:
> the TSC always available provided you compute your deltas a per cpu basis.
> You have another low resolution, low noise, but cheap time source: the
> count of scheduler ticks. Rather than coding an ad hoc algorithm,
> this information should be fed into a kalman filter.
> There are some lingering details: you need to invalidate the
> TSC when the processor speed changes: but this is controlled
> by powerd no? Second, if you can manage to throttle the CPU
> it suggests that you can also manage to pay higher time
> query costs and force clock_gettime calls.
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.
More information about the freebsd-performance