Re: excessive use of gettimeofday(2) and other syscalls
This is great info, thanks. Is it worth having some kind of environment variable tunable (or even compile time tunable) to have a fast gettimeofday then? Is there a complimentary body of code that assumes gettimeofday is precise? Manish On Wed, Sep 7, 2011 at 12:17 AM, Peter Jeremy peterjer...@acm.org wrote: On 2011-Sep-06 16:44:48 -0600, Manish Vachharajani mani...@lineratesystems.com wrote: Under 7.3 (haven't checked 8 or 9) this issue crops up because the time system call calls gettimeofday under the hood (see lib/libc/gen/time.c). As a result, the kernel tries to get an accurate subsecond resolution time that simply gets chopped to the nearest second. Under 8.x and later, time(3) uses clock_gettime(CLOCK_SECOND,...) rather than gettimeofday(). This is intended to be much cheaper than gettimeofday(). On 2011-Sep-06 21:15:55 -0400, Rayson Ho raysonlo...@gmail.com wrote: 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. There are 3 standard APIs for returning time of day: time(3) provides second precision gettimeofday(2) provides microsecond precision clock_gettime(2) provides nanosecond precision By default, FreeBSD attempts to provide resolution as close as possible to the precision - which makes the 2 system calls fairly expensive. In order to reduce the cost where the resolution isn't important, FreeBSD provides several non-standard clock types for clock_gettime(2). This approach differs from Linux - and it seems that there is a non-trivial body of code that assumes that calling gettimeofday() is very cheap. There is probably a good case for an API that provides a resolution of the order of a tick but there is no standard for this. -- Peter Jeremy -- Manish Vachharajani Founder LineRate Systems mani...@lineratesystems.com (609)635-9531 M ___ 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
Re: excessive use of gettimeofday(2) and other syscalls
Under 7.3 (haven't checked 8 or 9) this issue crops up because the time system call calls gettimeofday under the hood (see lib/libc/gen/time.c). As a result, the kernel tries to get an accurate subsecond resolution time that simply gets chopped to the nearest second. Lots of libraries assume that time is fast because it is fast under Linux. Every instance where I have seen this as a performance issue, the call has been to time not a direct call to gettimeofday. The latest openssl (not the one from FreeBSD, but the one from openssl.org has this issue for example. Manish On Tue, Sep 6, 2011 at 4:01 PM, Alexander Best arun...@freebsd.org wrote: hi there, in a recent discussion on current@ [1], it was discovered that chromium makes excessive use of gettimeofday(2). while searching google, i found other software that is/was having the same issue [2]. although this is a programming error, it would still be nice, if freebsd could issue a warning in cases like these. would it be possible to instruct freebsd to issue a warning, when a process issues a certain amount of syscalls per second (maybe tuneable via sysctl)? while calling gettimeofday(2) excessively isn't causing any harm, it triggers a lot of context switches and reduces performance. having such warnings in place could help a user identify such a process without having to use debugging tools, such as ktrace or dtrace. cheers. alex [1] http://www.mail-archive.com/freebsd-current@freebsd.org/msg131040.html [1] https://forum.transmissionbt.com/viewtopic.php?f=2t=11687 ___ 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 -- Manish Vachharajani Founder LineRate Systems mani...@lineratesystems.com (609)635-9531 M ___ 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
Re: excessive use of gettimeofday(2) and other syscalls
I believe that Linux uses a less precise clock that scales better across cores and is much faster than the precise clock FreeBSD uses even on one core. I don't know POSIX and other standards well enough to know if this is an acceptable solution on FreeBSD. However, there are less precise clocks on FreeBSD that are considerably faster (i.e., the _FAST variants). Someone with more expertise in these matters needs to comment on whether a change to using a _FAST clock is appropriate in libc. If it is acceptable, I think that it is easier to just make time use the FAST clock instead of getting programmers to change their programs. On Tue, Sep 6, 2011 at 6:41 PM, Eitan Adler li...@eitanadler.com wrote: On Tue, Sep 6, 2011 at 6:44 PM, Manish Vachharajani mani...@lineratesystems.com wrote: Lots of libraries assume that time is fast because it is fast under Linux. Silly question, but why can't we make it fast too? -- Eitan Adler 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
Re: excessive use of gettimeofday(2) and other syscalls
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
