On Wed, 27 Jul 2011, Gleb Kurtsou wrote:
On (27/07/2011 00:48), Alexander Best wrote:
On Mon Jul 25 11, Matthias Andree wrote:
Am 25.07.2011 09:21, schrieb Alexander Best:
On Mon Jul 25 11, Adrian Chadd wrote:
Is it perhaps doing disk IO using mmap?
how can i check, whether that's the case or not?
Use truss(1) for instance.
However, unless there are *practical* problems, a high number of
page faults is not an indication for problems. Although it may
sound scary, page faults are a feature of the memory management.
unfortunately truss(1) is crashing chromium :( i opened up a new
thread reagarding this issue on freebsd-current@.
Could you try ktrace? It works for me
another thing i noticed is the increase in system calls caused by
chromium. let's have a look at hub.freebsd.org:
*snip*
About 2.5k syscalls with chrome + a lot of other stuff running. 1.5k
without chrome.
Looks like there is a lot of clock_gettime and gettimeofday syscalls.
~ % kdump -m 1 -f ktrace.out | grep 'CALL .*gettime' | wc -l
24343
~ % kdump -E -m 1 -f ktrace.out | grep 'CALL .*gettime' | tail -20
12747 chrome 15.077376 CALL gettimeofday(0x7fffff7f9630,0x7fffff7f9640)
12747 chrome 15.077396 CALL clock_gettime(0x4,0x7fffffbfb6f0)
*snip*
Some work was done by kib@ to create a kernel page strong current time
and other misc info to eliminate gettimeofday kind syscalls. Bits of
it were commited but I'm not sure if it was finished. But anyway
calling gettimeofday hundreds of times per second is a chrome bug.
Is it Chrome or a supporting library that is making the call.
I have been trying, when I have time, to track down an issue similar to
this with Firefox (at least 4 and 5) that causes Xorg to run close to
100% while Firefox creates a new tab under certain circumstances. The
best example is to start the Add-ons Manager, search for something such
as Google in the Add-ons search box and click the "See all 1003 results"
at the bottom of the results page. Xorg is busy making a large number
of gettimeofday() and clock_gettime() calls amongst other calls.
This is with stable/8 r223876. The window manager does not matter. At
least, Fluxbox and TWM exhibit this. However, the size of the Firefox
window does (close to 1680x1050). Also, the window must be the top
window and not minimized. I have seen it on my system with nVidia
drivers and a VirtualBox guest hosted by WinXP.
I read a rumor in a forum--it must be true! ;)-- that it was Firefox
updating the title of the window incessantly as the tab is created. An
interesting workaround to this tab creation issue is to set
browser.tabs.loadDivertedInBackground to True. It does not fix all
cases.
i ran the following command twice. first time without running
chromium and the second time with chromium running:
otaku% vmstat -s|grep "system calls"; sleep 1; vmstat -s|grep "system calls"
2178187850 system calls
2178189739 system calls
otaku% vmstat -s|grep "system calls"; sleep 1; vmstat -s|grep "system calls"
2177998835 system calls
2178022003 system calls
so it's 2k/sec vs. 23k/sec!!!!
For my situation with Firefox, it jumps from about 2K/sec to 49K/sec.
Sean
--
s...@freebsd.org
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
