On Tue, Sep 6, 2011 at 7:15 PM, Rayson Ho <raysonlo...@gmail.com> wrote: > There are some recent discussions on the freebsd-current list. The > infrastructure is there to provide a common shared page for processes > to mmap into the address space... but according to Kip's comment, libc > support is not there yet: > > http://lists.freebsd.org/pipermail/freebsd-current/2011-June/025191.html > > Also, the kernel needs to update the variable in that shared page on > each clock interrupt (depending on the resolution I believe), and I > think that needs to be added too.
This would address the system call overhead but this isn't even close to the bulk of the cost. Here is data for the average time for a call using various clocks (via clock_gettime) and gettimeofday. This is for a single process on a Xeon 5654 (2.4 GHz) machine running FreeBSD 7.3 for amd64. As you can see the system call cost is not the main issue as the _FAST calls complete at 7.7 million calls per second in a single process. CLOCK_MONOTONIC: 848716 per second CLOCK_MONOTONIC_FAST: 7.73687e+06 per second CLOCK_MONOTONIC_PRECISE: 848744 per second CLOCK_REALTIME: 850795 per second CLOCK_REALTIME_FAST: 7.81742e+06 per second CLOCK_REALTIME_PRECISE: 849574 per second CLOCK_UPTIME: 848736 per second CLOCK_UPTIME_FAST: 7.84147e+06 per second CLOCK_UPTIME_PRECISE(1 ways): 848637 per second gettimeofday: 848637 per second > IMO, the time returned by gettimeofday does not need to be high > precision. There are higher resolution time APIs on Linux and I > believe the application programmers know when to use the slower but > more accurate clock API. (At least in Grid Engine we only need a quick > way of getting the current time, and we don't care if it is precise to > the nanosecond range.) Indeed, time only returns time in seconds so precision per se is unnecessary. The question is are there any strange behaviors across cores that lead to incorrect behavior if the _FAST timers are used. That is the question . For example, is it possible (and if possible, ok) for a process to call time() and get 946,000,001, then get scheduled to another cpu, and then make another call to time and get 946,000,000, making it look like time has gone backwards. I don't think standard timers allow for this to happen but the _FAST timers may (I'm just not sure), especially on an overloaded VM where the kernel could be scheduled out for longer than a tick. > See Linux security issue & solution: http://lwn.net/Articles/446528/ > See also the Google SoC idea: > http://wiki.freebsd.org/IdeasPage#Timecounter_Performance_Improvements_.28GSoC.29 > > Rayson > > ================================= > Grid Engine / Open Grid Scheduler > http://gridscheduler.sourceforge.net > > Manish _______________________________________________ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
