Re: excessive use of gettimeofday(2) and other syscalls
Sorry, my previous test is not accurate. I use both firefox and chromium to
open 13 same web pages( two of them are from www.sina.com.cn, other from
groups.google.com, wiki.sun.com and freebsd.org, both web browsers use
libcrossflash to drive linux flash plugin, not linuxulator on my amd64
8.2-stable , sorry I can not have access to youtube.com or facebook.com, I'm
in china),
and this is the result:
...
[root@lateaxfreebsd sys]# dtrace -n 'syscall::gettimeofday:entry / execname
== chrome || execname == firefox-bin|| execname == plugin-container /
{ @[execname] = count() } profile:::tick-1 { exit(0); } '
dtrace: description 'syscall::gettimeofday:entry ' matched 2 probes
CPU ID FUNCTION:NAME
1 97 :tick-1
plugin-container 7802
chrome 8403
firefox-bin 215777
if I close the two sina.com.cn tab( the big page), then
.
[root@lateaxfreebsd sys]# dtrace -n 'syscall::gettimeofday:entry / execname
== chrome || execname == firefox-bin|| execname == plugin-container /
{ @[execname] = count() } profile:::tick-1 { exit(0); } '
dtrace: description 'syscall::gettimeofday:entry ' matched 2 probes
CPU ID FUNCTION:NAME
1 97 :tick-1
chrome 65
plugin-container 2145
firefox-bin 268932
I think I can drive conclusion that chromium is much better than firefox
when rendering same page set, especially on static pages only 65 per second.
If we add opera to the list( opera not using flash plugin), it seems
opera does NOT use gettimeofday
.
[root@lateaxfreebsd sys]# dtrace -n 'syscall::gettimeofday:entry / execname
== chrome || execname == firefox-bin|| execname == plugin-container ||
execname == opera / { @[execname, probefunc] = count() } profile:::tick-1
{ exit(0); } '
dtrace: description 'syscall::gettimeofday:entry ' matched 2 probes
CPU ID FUNCTION:NAME
0 97 :tick-1
chrome gettimeofday 7632
plugin-container gettimeofday 8107
firefox-bin gettimeofday 232142
but it use more clock_gettime
.
[root@lateaxfreebsd sys]# dtrace -n 'syscall::clock_gettime:entry / execname
== chrome || execname == firefox-bin|| execname == plugin-container ||
execname == opera / { @[execname, probefunc] = count() } profile:::tick-1
{ exit(0); } '
dtrace: description 'syscall::clock_gettime:entry ' matched 2 probes
CPU ID FUNCTION:NAME
1 97 :tick-1
firefox-bin clock_gettime 634
chrome clock_gettime 839
plugin-container clock_gettime 1040
opera clock_gettime 14978
2011/9/10 Alexander Best arun...@freebsd.org
On Fri Sep 9 11, Alexander Best wrote:
On Fri Sep 9 11, Dieter BSD wrote:
Firefox 5 and 6 has more gettimeofday call than 2 per second on
my
amd64-8.2-stable box.
i don't see why chromium needs
to call gettimeofday(2) or any library function that triggers it more
than 3000 times a second.
What the BLEEP are web browsers doing that they need the clock
so often?
I suspect the answer is the same as why firefox uses significant
amounts
of CPU when it should be idle, why it uses memory without bound
(I actually had to add ulimit to my shell's rc file :-( ), and
so on.
Using links -g,
ktrace -di -tc -p6951; sleep 1; ktrace -C; kdump|wc -l
gives a typical count of 300-400, highest count seen: 1454.
well that measurement is probably unfair. my measurements included all
opened
tabs (~ 15), running plugins and extensions. if i disable all of those
extra
stuff and use only a single tab, chromium produces less syscalls than
links:
270
...however sites such as facebook produce a much higher syscall peek under
chromium. with only one tab opened with youtube.com in it, chromium has a
typical syscall count of 700-2000. i guess this is due to stuff like js,
html5
and friends.
if i enable the flash plugins with only 1 single tab (youtube.com), the
syscall
count climbs to ~ 8000 with a peak at 19000 when youtube.com wasn't
completely
loaded. so the high syscall count is not only chromiums fault, but a
combination of chromium, flash and the linuxulator.
i believe further linuxulator improvements might reduce syscalls in this
scenario.
also with chromium 15, the syscall count is supposed to drop quite
noticably
(as mentioned in a previous message).
cheers.
alex
cheers.
alex
What we need, is a sanely written web browser that has the
features we need. Unfortunately the last time I checked,
links and dillo both lacked features needed for online
shopping/banking.
___
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
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To
Re: excessive use of gettimeofday(2) and other syscalls
On 2011-Sep-07 12:41:54 -0600, Manish Vachharajani mani...@lineratesystems.com wrote: 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? Maybe. rwatson@ produced a preloadable .so to do this - see http://www.watson.org/~robert/freebsd/clock/ Is there a complimentary body of code that assumes gettimeofday is precise? I'm not aware of any but it's not necessarily trivial to identify such code - it's unlikely to fail outright but instead may deliver results that may not be as accurate as the author intended. I think a better way of looking at the problem is that some code was designed on the assumption that certain operations were cheap and therefore uses those operations more freely than it would have had those operations been more expensive. -- Peter Jeremy pgp8RtgcBLrmz.pgp Description: PGP signature
Re: excessive use of gettimeofday(2) and other syscalls
what version of chromium are you using? I use chromium-13.0.782.215 on amd64 8.2-stable, the gettimeofday call is far less than 2 per second, about 20 per second, but I notice old version has this bug, but latest version has fixed it. Maybe you should update your chromium and try again. Firefox 5 and 6 has more gettimeofday call than 2 per second on my amd64-8.2-stable box. 2011/9/7 Alexander Best arun...@freebsd.org On Wed Sep 7 11, Peter Jeremy 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. chromium is triggering ~20.000 gettimeofday(2) calls per second on my machine. i'm running CURRENT on amd64. cheers. alex -- Peter Jeremy ___ 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 ___ 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 Fri Sep 9 11, Paul Ambrose wrote: what version of chromium are you using? I use chromium-13.0.782.215 on amd64 8.2-stable, the gettimeofday call is far less than 2 per second, about 20 per second, but I notice old version has this bug, but latest version has fixed it. Maybe you should update your chromium and try again. i'm running chromium-13.0.782.220 and sudo ktrace -di -tc -p1758; sleep 1; sudo ktrace -C; sudo kdump|grep gettimeofday|wc -l gives me 3056. so the number has decresed, yet i don't see why chromium needs to call gettimeofday(2) or any library function that triggers it more than 3000 times a second. also sudo ktrace -di -tc -p1758; sleep 1; sudo ktrace -C; sudo kdump|wc -l is returning 16695. that also seems like a pretty high syscall count in general for only 1 second. cheers. alex Firefox 5 and 6 has more gettimeofday call than 2 per second on my amd64-8.2-stable box. 2011/9/7 Alexander Best arun...@freebsd.org On Wed Sep 7 11, Peter Jeremy 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. chromium is triggering ~20.000 gettimeofday(2) calls per second on my machine. i'm running CURRENT on amd64. cheers. alex -- Peter Jeremy ___ 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 ___ 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
Firefox 5 and 6 has more gettimeofday call than 2 per second on my amd64-8.2-stable box. i don't see why chromium needs to call gettimeofday(2) or any library function that triggers it more than 3000 times a second. What the BLEEP are web browsers doing that they need the clock so often? I suspect the answer is the same as why firefox uses significant amounts of CPU when it should be idle, why it uses memory without bound (I actually had to add ulimit to my shell's rc file :-( ), and so on. Using links -g, ktrace -di -tc -p6951; sleep 1; ktrace -C; kdump|wc -l gives a typical count of 300-400, highest count seen: 1454. What we need, is a sanely written web browser that has the features we need. Unfortunately the last time I checked, links and dillo both lacked features needed for online shopping/banking. ___ 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 Fri Sep 9 11, Dieter BSD wrote: Firefox 5 and 6 has more gettimeofday call than 2 per second on my amd64-8.2-stable box. i don't see why chromium needs to call gettimeofday(2) or any library function that triggers it more than 3000 times a second. What the BLEEP are web browsers doing that they need the clock so often? I suspect the answer is the same as why firefox uses significant amounts of CPU when it should be idle, why it uses memory without bound (I actually had to add ulimit to my shell's rc file :-( ), and so on. Using links -g, ktrace -di -tc -p6951; sleep 1; ktrace -C; kdump|wc -l gives a typical count of 300-400, highest count seen: 1454. well that measurement is probably unfair. my measurements included all opened tabs (~ 15), running plugins and extensions. if i disable all of those extra stuff and use only a single tab, chromium produces less syscalls than links: 270 cheers. alex What we need, is a sanely written web browser that has the features we need. Unfortunately the last time I checked, links and dillo both lacked features needed for online shopping/banking. ___ 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 Fri Sep 9 11, Alexander Best wrote: On Fri Sep 9 11, Dieter BSD wrote: Firefox 5 and 6 has more gettimeofday call than 2 per second on my amd64-8.2-stable box. i don't see why chromium needs to call gettimeofday(2) or any library function that triggers it more than 3000 times a second. What the BLEEP are web browsers doing that they need the clock so often? I suspect the answer is the same as why firefox uses significant amounts of CPU when it should be idle, why it uses memory without bound (I actually had to add ulimit to my shell's rc file :-( ), and so on. Using links -g, ktrace -di -tc -p6951; sleep 1; ktrace -C; kdump|wc -l gives a typical count of 300-400, highest count seen: 1454. well that measurement is probably unfair. my measurements included all opened tabs (~ 15), running plugins and extensions. if i disable all of those extra stuff and use only a single tab, chromium produces less syscalls than links: 270 ...however sites such as facebook produce a much higher syscall peek under chromium. with only one tab opened with youtube.com in it, chromium has a typical syscall count of 700-2000. i guess this is due to stuff like js, html5 and friends. if i enable the flash plugins with only 1 single tab (youtube.com), the syscall count climbs to ~ 8000 with a peak at 19000 when youtube.com wasn't completely loaded. so the high syscall count is not only chromiums fault, but a combination of chromium, flash and the linuxulator. i believe further linuxulator improvements might reduce syscalls in this scenario. also with chromium 15, the syscall count is supposed to drop quite noticably (as mentioned in a previous message). cheers. alex cheers. alex What we need, is a sanely written web browser that has the features we need. Unfortunately the last time I checked, links and dillo both lacked features needed for online shopping/banking. ___ 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 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 pgpvoAwjmooj4.pgp Description: PGP signature
Re: excessive use of gettimeofday(2) and other syscalls
On Wed Sep 7 11, Peter Jeremy 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. chromium is triggering ~20.000 gettimeofday(2) calls per second on my machine. i'm running CURRENT on amd64. cheers. alex -- Peter Jeremy ___ 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
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
excessive use of gettimeofday(2) and other syscalls
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
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
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 ___ 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
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. 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.) 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 On Tue, Sep 6, 2011 at 8:49 PM, Manish Vachharajani mani...@lineratesystems.com wrote: 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 -- Rayson == Open Grid Scheduler - The Official Open Source Grid Engine http://gridscheduler.sourceforge.net/ ___ 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
