Re: chromium port causing massive I/O faults
Surely you could trace the X11 IPC in dtrace or something, and see what the actual messages are? (Surely there's X11 protocol profiling stuff out there?) Adrian On 28 July 2011 10:12, Sean C. Farley s...@freebsd.org wrote: 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(0x7f7f9630,0x7f7f9640) 12747 chrome 15.077396 CALL clock_gettime(0x4,0x7fbfb6f0) *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
Re: chromium port causing massive I/O faults
On Wed Jul 27 11, René Ladan wrote: 2011/7/27 Alexander Best arun...@freebsd.org: On Wed Jul 27 11, René Ladan wrote: 2011/7/27 Gleb Kurtsou gleb.kurt...@gmail.com: 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: uptime = 149 days and 'vmstat -s' reports: 2168697753 cpu context switches 2266220366 device interrupts 2902880931 software interrupts 3779075897 traps 902107847 system calls now on my box: uptime = 2 days and 'vmstat -s' reports: 1155995386 cpu context switches 164577882 device interrupts 189456976 software interrupts 137007580 traps 2178434582 system calls 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(0x7f7f9630,0x7f7f9640) 12747 chrome 15.077396 CALL clock_gettime(0x4,0x7fbfb6f0) 12747 chrome 15.077497 CALL gettimeofday(0x7fbfb650,0x7fbfb660) 12747 chrome 15.077609 CALL gettimeofday(0x7fbfb650,0x7fbfb660) 12747 chrome 15.077723 CALL gettimeofday(0x7fbfb650,0) 12747 chrome 15.077845 CALL clock_gettime(0,0x7fbfb2b0) 12747 chrome 15.078337 CALL clock_gettime(0x4,0x7f9fa630) 12747 chrome 15.078544 CALL clock_gettime(0x4,0x7f9fa650) 12747 chrome 15.078587 CALL clock_gettime(0x4,0x7f9fa650) 12747 chrome 15.078632 CALL clock_gettime(0x4,0x7f9fa650) 12747 chrome 15.078674 CALL clock_gettime(0x4,0x7f9fa650) 12747 chrome 15.082803 CALL gettimeofday(0x7edd3630,0x7edd3640) 12747 chrome 15.084644 CALL gettimeofday(0x7fbfb650,0x7fbfb660) 12747 chrome 15.084746 CALL clock_gettime(0x4,0x7fbfb670) 12747 chrome 15.084815 CALL clock_gettime(0x4,0x7fbfb670) 12747 chrome 15.086620 CALL gettimeofday(0x7efd4650,0x7efd4660) 12747 chrome 15.086736 CALL clock_gettime(0x4,0x7efd4670) 12747 chrome 15.086815 CALL clock_gettime(0x4,0x7efd4670) 12747 chrome 15.098315 CALL gettimeofday(0x7fffafe0,0x7fffaff0) 12747 chrome 15.098680 CALL clock_gettime(0x4,0x7fffb250) 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. FreeBSD 9.0-CURRENT #2 r224003+777e962: Thu Jul 14 13:04:55 EEST 2011 chromium-11.0.696.57_1 ^ Can you retry with an up-to-date version of www/chromium? The codebase of chromium changes quite fast so not using the latest version in ports might render obsolete (and upstream unsupported) results. my tests were done with chromium-12.0.742.124 btw. Ok, I'll do some tests with the beta version from the chruetertee repository (13.0.782.99). it looks as if this issue was fixed somewhere between 14.0.797.0 and 14.0.817.0 according to http://code.google.com/p/chromium/issues/detail?id=77625 René -- http://www.rene-ladan.nl/ ___ 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
Re: chromium port causing massive I/O faults
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: uptime = 149 days and 'vmstat -s' reports: 2168697753 cpu context switches 2266220366 device interrupts 2902880931 software interrupts 3779075897 traps 902107847 system calls now on my box: uptime = 2 days and 'vmstat -s' reports: 1155995386 cpu context switches 164577882 device interrupts 189456976 software interrupts 137007580 traps 2178434582 system calls 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(0x7f7f9630,0x7f7f9640) 12747 chrome 15.077396 CALL clock_gettime(0x4,0x7fbfb6f0) 12747 chrome 15.077497 CALL gettimeofday(0x7fbfb650,0x7fbfb660) 12747 chrome 15.077609 CALL gettimeofday(0x7fbfb650,0x7fbfb660) 12747 chrome 15.077723 CALL gettimeofday(0x7fbfb650,0) 12747 chrome 15.077845 CALL clock_gettime(0,0x7fbfb2b0) 12747 chrome 15.078337 CALL clock_gettime(0x4,0x7f9fa630) 12747 chrome 15.078544 CALL clock_gettime(0x4,0x7f9fa650) 12747 chrome 15.078587 CALL clock_gettime(0x4,0x7f9fa650) 12747 chrome 15.078632 CALL clock_gettime(0x4,0x7f9fa650) 12747 chrome 15.078674 CALL clock_gettime(0x4,0x7f9fa650) 12747 chrome 15.082803 CALL gettimeofday(0x7edd3630,0x7edd3640) 12747 chrome 15.084644 CALL gettimeofday(0x7fbfb650,0x7fbfb660) 12747 chrome 15.084746 CALL clock_gettime(0x4,0x7fbfb670) 12747 chrome 15.084815 CALL clock_gettime(0x4,0x7fbfb670) 12747 chrome 15.086620 CALL gettimeofday(0x7efd4650,0x7efd4660) 12747 chrome 15.086736 CALL clock_gettime(0x4,0x7efd4670) 12747 chrome 15.086815 CALL clock_gettime(0x4,0x7efd4670) 12747 chrome 15.098315 CALL gettimeofday(0x7fffafe0,0x7fffaff0) 12747 chrome 15.098680 CALL clock_gettime(0x4,0x7fffb250) 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. FreeBSD 9.0-CURRENT #2 r224003+777e962: Thu Jul 14 13:04:55 EEST 2011 chromium-11.0.696.57_1 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 cheers. alex ___ 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
Re: chromium port causing massive I/O faults
On Wed Jul 27 11, 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: uptime = 149 days and 'vmstat -s' reports: 2168697753 cpu context switches 2266220366 device interrupts 2902880931 software interrupts 3779075897 traps 902107847 system calls now on my box: uptime = 2 days and 'vmstat -s' reports: 1155995386 cpu context switches 164577882 device interrupts 189456976 software interrupts 137007580 traps 2178434582 system calls 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(0x7f7f9630,0x7f7f9640) 12747 chrome 15.077396 CALL clock_gettime(0x4,0x7fbfb6f0) 12747 chrome 15.077497 CALL gettimeofday(0x7fbfb650,0x7fbfb660) 12747 chrome 15.077609 CALL gettimeofday(0x7fbfb650,0x7fbfb660) 12747 chrome 15.077723 CALL gettimeofday(0x7fbfb650,0) 12747 chrome 15.077845 CALL clock_gettime(0,0x7fbfb2b0) 12747 chrome 15.078337 CALL clock_gettime(0x4,0x7f9fa630) 12747 chrome 15.078544 CALL clock_gettime(0x4,0x7f9fa650) 12747 chrome 15.078587 CALL clock_gettime(0x4,0x7f9fa650) 12747 chrome 15.078632 CALL clock_gettime(0x4,0x7f9fa650) 12747 chrome 15.078674 CALL clock_gettime(0x4,0x7f9fa650) 12747 chrome 15.082803 CALL gettimeofday(0x7edd3630,0x7edd3640) 12747 chrome 15.084644 CALL gettimeofday(0x7fbfb650,0x7fbfb660) 12747 chrome 15.084746 CALL clock_gettime(0x4,0x7fbfb670) 12747 chrome 15.084815 CALL clock_gettime(0x4,0x7fbfb670) 12747 chrome 15.086620 CALL gettimeofday(0x7efd4650,0x7efd4660) 12747 chrome 15.086736 CALL clock_gettime(0x4,0x7efd4670) 12747 chrome 15.086815 CALL clock_gettime(0x4,0x7efd4670) 12747 chrome 15.098315 CALL gettimeofday(0x7fffafe0,0x7fffaff0) 12747 chrome 15.098680 CALL clock_gettime(0x4,0x7fffb250) 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. *lol* i did exactly the same measurements, you did. :) here are my results: otaku% kdump|grep CALL mmap|wc 7242896 58468 otaku% kdump -s|grep CALL clock_gettime|wc 49545 198180 2772674 otaku% kdump -s|grep CALL linux_clock_gettime|wc 40185 160740 2491298 otaku% kdump -s|grep CALL linux_gettimeofday|wc 21670 86680 1278530 otaku% kdump -s|grep CALL gettimeofday|wc 8173 32692 525053 otaku% kdump -s|grep CALL linux_sys_futex|wc 6191 24764 548800 cheers. alex FreeBSD 9.0-CURRENT #2 r224003+777e962: Thu Jul 14 13:04:55 EEST 2011 chromium-11.0.696.57_1 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 cheers. alex ___ 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
Re: chromium port causing massive I/O faults
2011/7/27 Gleb Kurtsou gleb.kurt...@gmail.com: 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: uptime = 149 days and 'vmstat -s' reports: 2168697753 cpu context switches 2266220366 device interrupts 2902880931 software interrupts 3779075897 traps 902107847 system calls now on my box: uptime = 2 days and 'vmstat -s' reports: 1155995386 cpu context switches 164577882 device interrupts 189456976 software interrupts 137007580 traps 2178434582 system calls 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(0x7f7f9630,0x7f7f9640) 12747 chrome 15.077396 CALL clock_gettime(0x4,0x7fbfb6f0) 12747 chrome 15.077497 CALL gettimeofday(0x7fbfb650,0x7fbfb660) 12747 chrome 15.077609 CALL gettimeofday(0x7fbfb650,0x7fbfb660) 12747 chrome 15.077723 CALL gettimeofday(0x7fbfb650,0) 12747 chrome 15.077845 CALL clock_gettime(0,0x7fbfb2b0) 12747 chrome 15.078337 CALL clock_gettime(0x4,0x7f9fa630) 12747 chrome 15.078544 CALL clock_gettime(0x4,0x7f9fa650) 12747 chrome 15.078587 CALL clock_gettime(0x4,0x7f9fa650) 12747 chrome 15.078632 CALL clock_gettime(0x4,0x7f9fa650) 12747 chrome 15.078674 CALL clock_gettime(0x4,0x7f9fa650) 12747 chrome 15.082803 CALL gettimeofday(0x7edd3630,0x7edd3640) 12747 chrome 15.084644 CALL gettimeofday(0x7fbfb650,0x7fbfb660) 12747 chrome 15.084746 CALL clock_gettime(0x4,0x7fbfb670) 12747 chrome 15.084815 CALL clock_gettime(0x4,0x7fbfb670) 12747 chrome 15.086620 CALL gettimeofday(0x7efd4650,0x7efd4660) 12747 chrome 15.086736 CALL clock_gettime(0x4,0x7efd4670) 12747 chrome 15.086815 CALL clock_gettime(0x4,0x7efd4670) 12747 chrome 15.098315 CALL gettimeofday(0x7fffafe0,0x7fffaff0) 12747 chrome 15.098680 CALL clock_gettime(0x4,0x7fffb250) 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. FreeBSD 9.0-CURRENT #2 r224003+777e962: Thu Jul 14 13:04:55 EEST 2011 chromium-11.0.696.57_1 ^ Can you retry with an up-to-date version of www/chromium? The codebase of chromium changes quite fast so not using the latest version in ports might render obsolete (and upstream unsupported) results. René -- http://www.rene-ladan.nl/ ___ 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
Re: chromium port causing massive I/O faults
On Wed Jul 27 11, René Ladan wrote: 2011/7/27 Gleb Kurtsou gleb.kurt...@gmail.com: 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: uptime = 149 days and 'vmstat -s' reports: 2168697753 cpu context switches 2266220366 device interrupts 2902880931 software interrupts 3779075897 traps 902107847 system calls now on my box: uptime = 2 days and 'vmstat -s' reports: 1155995386 cpu context switches 164577882 device interrupts 189456976 software interrupts 137007580 traps 2178434582 system calls 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(0x7f7f9630,0x7f7f9640) 12747 chrome 15.077396 CALL clock_gettime(0x4,0x7fbfb6f0) 12747 chrome 15.077497 CALL gettimeofday(0x7fbfb650,0x7fbfb660) 12747 chrome 15.077609 CALL gettimeofday(0x7fbfb650,0x7fbfb660) 12747 chrome 15.077723 CALL gettimeofday(0x7fbfb650,0) 12747 chrome 15.077845 CALL clock_gettime(0,0x7fbfb2b0) 12747 chrome 15.078337 CALL clock_gettime(0x4,0x7f9fa630) 12747 chrome 15.078544 CALL clock_gettime(0x4,0x7f9fa650) 12747 chrome 15.078587 CALL clock_gettime(0x4,0x7f9fa650) 12747 chrome 15.078632 CALL clock_gettime(0x4,0x7f9fa650) 12747 chrome 15.078674 CALL clock_gettime(0x4,0x7f9fa650) 12747 chrome 15.082803 CALL gettimeofday(0x7edd3630,0x7edd3640) 12747 chrome 15.084644 CALL gettimeofday(0x7fbfb650,0x7fbfb660) 12747 chrome 15.084746 CALL clock_gettime(0x4,0x7fbfb670) 12747 chrome 15.084815 CALL clock_gettime(0x4,0x7fbfb670) 12747 chrome 15.086620 CALL gettimeofday(0x7efd4650,0x7efd4660) 12747 chrome 15.086736 CALL clock_gettime(0x4,0x7efd4670) 12747 chrome 15.086815 CALL clock_gettime(0x4,0x7efd4670) 12747 chrome 15.098315 CALL gettimeofday(0x7fffafe0,0x7fffaff0) 12747 chrome 15.098680 CALL clock_gettime(0x4,0x7fffb250) 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. FreeBSD 9.0-CURRENT #2 r224003+777e962: Thu Jul 14 13:04:55 EEST 2011 chromium-11.0.696.57_1 ^ Can you retry with an up-to-date version of www/chromium? The codebase of chromium changes quite fast so not using the latest version in ports might render obsolete (and upstream unsupported) results. my tests were done with chromium-12.0.742.124 btw. René -- http://www.rene-ladan.nl/ ___ 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
Re: chromium port causing massive I/O faults
2011/7/27 Alexander Best arun...@freebsd.org: On Wed Jul 27 11, René Ladan wrote: 2011/7/27 Gleb Kurtsou gleb.kurt...@gmail.com: 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: uptime = 149 days and 'vmstat -s' reports: 2168697753 cpu context switches 2266220366 device interrupts 2902880931 software interrupts 3779075897 traps 902107847 system calls now on my box: uptime = 2 days and 'vmstat -s' reports: 1155995386 cpu context switches 164577882 device interrupts 189456976 software interrupts 137007580 traps 2178434582 system calls 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(0x7f7f9630,0x7f7f9640) 12747 chrome 15.077396 CALL clock_gettime(0x4,0x7fbfb6f0) 12747 chrome 15.077497 CALL gettimeofday(0x7fbfb650,0x7fbfb660) 12747 chrome 15.077609 CALL gettimeofday(0x7fbfb650,0x7fbfb660) 12747 chrome 15.077723 CALL gettimeofday(0x7fbfb650,0) 12747 chrome 15.077845 CALL clock_gettime(0,0x7fbfb2b0) 12747 chrome 15.078337 CALL clock_gettime(0x4,0x7f9fa630) 12747 chrome 15.078544 CALL clock_gettime(0x4,0x7f9fa650) 12747 chrome 15.078587 CALL clock_gettime(0x4,0x7f9fa650) 12747 chrome 15.078632 CALL clock_gettime(0x4,0x7f9fa650) 12747 chrome 15.078674 CALL clock_gettime(0x4,0x7f9fa650) 12747 chrome 15.082803 CALL gettimeofday(0x7edd3630,0x7edd3640) 12747 chrome 15.084644 CALL gettimeofday(0x7fbfb650,0x7fbfb660) 12747 chrome 15.084746 CALL clock_gettime(0x4,0x7fbfb670) 12747 chrome 15.084815 CALL clock_gettime(0x4,0x7fbfb670) 12747 chrome 15.086620 CALL gettimeofday(0x7efd4650,0x7efd4660) 12747 chrome 15.086736 CALL clock_gettime(0x4,0x7efd4670) 12747 chrome 15.086815 CALL clock_gettime(0x4,0x7efd4670) 12747 chrome 15.098315 CALL gettimeofday(0x7fffafe0,0x7fffaff0) 12747 chrome 15.098680 CALL clock_gettime(0x4,0x7fffb250) 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. FreeBSD 9.0-CURRENT #2 r224003+777e962: Thu Jul 14 13:04:55 EEST 2011 chromium-11.0.696.57_1 ^ Can you retry with an up-to-date version of www/chromium? The codebase of chromium changes quite fast so not using the latest version in ports might render obsolete (and upstream unsupported) results. my tests were done with chromium-12.0.742.124 btw. Ok, I'll do some tests with the beta version from the chruetertee repository (13.0.782.99). René -- http://www.rene-ladan.nl/ ___ 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
Re: chromium port causing massive I/O faults
On Wed Jul 27 11, René Ladan wrote: 2011/7/27 Alexander Best arun...@freebsd.org: On Wed Jul 27 11, René Ladan wrote: 2011/7/27 Gleb Kurtsou gleb.kurt...@gmail.com: 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: uptime = 149 days and 'vmstat -s' reports: 2168697753 cpu context switches 2266220366 device interrupts 2902880931 software interrupts 3779075897 traps 902107847 system calls now on my box: uptime = 2 days and 'vmstat -s' reports: 1155995386 cpu context switches 164577882 device interrupts 189456976 software interrupts 137007580 traps 2178434582 system calls 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(0x7f7f9630,0x7f7f9640) 12747 chrome 15.077396 CALL clock_gettime(0x4,0x7fbfb6f0) 12747 chrome 15.077497 CALL gettimeofday(0x7fbfb650,0x7fbfb660) 12747 chrome 15.077609 CALL gettimeofday(0x7fbfb650,0x7fbfb660) 12747 chrome 15.077723 CALL gettimeofday(0x7fbfb650,0) 12747 chrome 15.077845 CALL clock_gettime(0,0x7fbfb2b0) 12747 chrome 15.078337 CALL clock_gettime(0x4,0x7f9fa630) 12747 chrome 15.078544 CALL clock_gettime(0x4,0x7f9fa650) 12747 chrome 15.078587 CALL clock_gettime(0x4,0x7f9fa650) 12747 chrome 15.078632 CALL clock_gettime(0x4,0x7f9fa650) 12747 chrome 15.078674 CALL clock_gettime(0x4,0x7f9fa650) 12747 chrome 15.082803 CALL gettimeofday(0x7edd3630,0x7edd3640) 12747 chrome 15.084644 CALL gettimeofday(0x7fbfb650,0x7fbfb660) 12747 chrome 15.084746 CALL clock_gettime(0x4,0x7fbfb670) 12747 chrome 15.084815 CALL clock_gettime(0x4,0x7fbfb670) 12747 chrome 15.086620 CALL gettimeofday(0x7efd4650,0x7efd4660) 12747 chrome 15.086736 CALL clock_gettime(0x4,0x7efd4670) 12747 chrome 15.086815 CALL clock_gettime(0x4,0x7efd4670) 12747 chrome 15.098315 CALL gettimeofday(0x7fffafe0,0x7fffaff0) 12747 chrome 15.098680 CALL clock_gettime(0x4,0x7fffb250) 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. ...also the number of context switches is very high. the following 'vmstat -s' output was taken after only 32 minutes of uptime and chromium running for ~ 10 minutes: 39775038 cpu context switches 1716910 device interrupts 1707161 software interrupts 1764371 traps 57319358 system calls 15 kernel threads created 2120 fork() calls 11 vfork() calls 25 rfork() calls 0 swap pager pageins 0 swap pager pages paged in 0 swap pager pageouts 0 swap pager pages paged out 71184 vnode pager pageins 102181 vnode pager pages paged in 13321 vnode pager pageouts 67437 vnode pager pages paged out 0 page daemon wakeups 0 pages examined by the page daemon 4662 pages reactivated 93964 copy-on-write faults 274 copy-on-write optimized faults 358563 zero fill pages zeroed 319 zero fill pages prezeroed 302 intransit blocking page faults 740518 total VM faults taken 0 pages affected by kernel thread creation 1130760 pages affected by fork() 17316 pages affected by vfork() 22319 pages affected by rfork() 7162 pages cached 693935 pages freed 0 pages freed by daemon 396060 pages freed by exiting processes 34690 pages active 88551 pages inactive 164 pages in VM cache 76703 pages wired down 301738 pages free 4096 bytes per page 426219 total name lookups cache hits (87% pos + 2% neg) system 0%
Re: chromium port causing massive I/O faults
On (27/07/2011 09:18), Alexander Best wrote: On Wed Jul 27 11, 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: uptime = 149 days and 'vmstat -s' reports: 2168697753 cpu context switches 2266220366 device interrupts 2902880931 software interrupts 3779075897 traps 902107847 system calls now on my box: uptime = 2 days and 'vmstat -s' reports: 1155995386 cpu context switches 164577882 device interrupts 189456976 software interrupts 137007580 traps 2178434582 system calls 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(0x7f7f9630,0x7f7f9640) 12747 chrome 15.077396 CALL clock_gettime(0x4,0x7fbfb6f0) 12747 chrome 15.077497 CALL gettimeofday(0x7fbfb650,0x7fbfb660) 12747 chrome 15.077609 CALL gettimeofday(0x7fbfb650,0x7fbfb660) 12747 chrome 15.077723 CALL gettimeofday(0x7fbfb650,0) 12747 chrome 15.077845 CALL clock_gettime(0,0x7fbfb2b0) 12747 chrome 15.078337 CALL clock_gettime(0x4,0x7f9fa630) 12747 chrome 15.078544 CALL clock_gettime(0x4,0x7f9fa650) 12747 chrome 15.078587 CALL clock_gettime(0x4,0x7f9fa650) 12747 chrome 15.078632 CALL clock_gettime(0x4,0x7f9fa650) 12747 chrome 15.078674 CALL clock_gettime(0x4,0x7f9fa650) 12747 chrome 15.082803 CALL gettimeofday(0x7edd3630,0x7edd3640) 12747 chrome 15.084644 CALL gettimeofday(0x7fbfb650,0x7fbfb660) 12747 chrome 15.084746 CALL clock_gettime(0x4,0x7fbfb670) 12747 chrome 15.084815 CALL clock_gettime(0x4,0x7fbfb670) 12747 chrome 15.086620 CALL gettimeofday(0x7efd4650,0x7efd4660) 12747 chrome 15.086736 CALL clock_gettime(0x4,0x7efd4670) 12747 chrome 15.086815 CALL clock_gettime(0x4,0x7efd4670) 12747 chrome 15.098315 CALL gettimeofday(0x7fffafe0,0x7fffaff0) 12747 chrome 15.098680 CALL clock_gettime(0x4,0x7fffb250) 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. *lol* i did exactly the same measurements, you did. :) here are my results: otaku% kdump|grep CALL mmap|wc 7242896 58468 otaku% kdump -s|grep CALL clock_gettime|wc 49545 198180 2772674 otaku% kdump -s|grep CALL linux_clock_gettime|wc 40185 160740 2491298 otaku% kdump -s|grep CALL linux_gettimeofday|wc 21670 86680 1278530 otaku% kdump -s|grep CALL gettimeofday|wc 8173 32692 525053 otaku% kdump -s|grep CALL linux_sys_futex|wc 6191 24764 548800 I suppose linux_* stuff comes from flashplugin. Clearly flash generates more gettime syscalls than chrome itself. Unfortunately the only way to fix this mess in a linux centric world is to implement syscall free gettimeofday with linux ABI support. syscall-free gettimeofday discussion: http://freebsd.1045724.n5.nabble.com/fast-syscall-free-gettimeofday-td4488301.html ___ 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
Re: chromium port causing massive I/O faults
On Wed Jul 27 11, Gleb Kurtsou wrote: On (27/07/2011 09:18), Alexander Best wrote: On Wed Jul 27 11, 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: uptime = 149 days and 'vmstat -s' reports: 2168697753 cpu context switches 2266220366 device interrupts 2902880931 software interrupts 3779075897 traps 902107847 system calls now on my box: uptime = 2 days and 'vmstat -s' reports: 1155995386 cpu context switches 164577882 device interrupts 189456976 software interrupts 137007580 traps 2178434582 system calls 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(0x7f7f9630,0x7f7f9640) 12747 chrome 15.077396 CALL clock_gettime(0x4,0x7fbfb6f0) 12747 chrome 15.077497 CALL gettimeofday(0x7fbfb650,0x7fbfb660) 12747 chrome 15.077609 CALL gettimeofday(0x7fbfb650,0x7fbfb660) 12747 chrome 15.077723 CALL gettimeofday(0x7fbfb650,0) 12747 chrome 15.077845 CALL clock_gettime(0,0x7fbfb2b0) 12747 chrome 15.078337 CALL clock_gettime(0x4,0x7f9fa630) 12747 chrome 15.078544 CALL clock_gettime(0x4,0x7f9fa650) 12747 chrome 15.078587 CALL clock_gettime(0x4,0x7f9fa650) 12747 chrome 15.078632 CALL clock_gettime(0x4,0x7f9fa650) 12747 chrome 15.078674 CALL clock_gettime(0x4,0x7f9fa650) 12747 chrome 15.082803 CALL gettimeofday(0x7edd3630,0x7edd3640) 12747 chrome 15.084644 CALL gettimeofday(0x7fbfb650,0x7fbfb660) 12747 chrome 15.084746 CALL clock_gettime(0x4,0x7fbfb670) 12747 chrome 15.084815 CALL clock_gettime(0x4,0x7fbfb670) 12747 chrome 15.086620 CALL gettimeofday(0x7efd4650,0x7efd4660) 12747 chrome 15.086736 CALL clock_gettime(0x4,0x7efd4670) 12747 chrome 15.086815 CALL clock_gettime(0x4,0x7efd4670) 12747 chrome 15.098315 CALL gettimeofday(0x7fffafe0,0x7fffaff0) 12747 chrome 15.098680 CALL clock_gettime(0x4,0x7fffb250) 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. *lol* i did exactly the same measurements, you did. :) here are my results: otaku% kdump|grep CALL mmap|wc 7242896 58468 otaku% kdump -s|grep CALL clock_gettime|wc 49545 198180 2772674 otaku% kdump -s|grep CALL linux_clock_gettime|wc 40185 160740 2491298 otaku% kdump -s|grep CALL linux_gettimeofday|wc 21670 86680 1278530 otaku% kdump -s|grep CALL gettimeofday|wc 8173 32692 525053 otaku% kdump -s|grep CALL linux_sys_futex|wc 6191 24764 548800 I suppose linux_* stuff comes from flashplugin. Clearly flash generates more gettime syscalls than chrome itself. Unfortunately the only way to fix this mess in a linux centric world is to implement syscall free gettimeofday with linux ABI support. syscall-free gettimeofday discussion: http://freebsd.1045724.n5.nabble.com/fast-syscall-free-gettimeofday-td4488301.html thanks. this linux article is also very interesting in this context: http://lwn.net/Articles/18411/ ...they sorta claim that implementing gettimeofday() in userland is extremely difficult. cheers. alex ___ 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
Re: chromium port causing massive I/O faults
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(0x7f7f9630,0x7f7f9640) 12747 chrome 15.077396 CALL clock_gettime(0x4,0x7fbfb6f0) *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
Re: chromium port causing massive I/O faults
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@. another thing i noticed is the increase in system calls caused by chromium. let's have a look at hub.freebsd.org: uptime = 149 days and 'vmstat -s' reports: 2168697753 cpu context switches 2266220366 device interrupts 2902880931 software interrupts 3779075897 traps 902107847 system calls now on my box: uptime = 2 days and 'vmstat -s' reports: 1155995386 cpu context switches 164577882 device interrupts 189456976 software interrupts 137007580 traps 2178434582 system calls 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 cheers. alex ___ 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
Re: chromium port causing massive I/O faults
Again, if it's doing lots of mmap based IO, it's likely not a big deal. Try getting dtrace to give you useful info? Adrian On 27 July 2011 08:48, Alexander Best arun...@freebsd.org 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@. another thing i noticed is the increase in system calls caused by chromium. let's have a look at hub.freebsd.org: uptime = 149 days and 'vmstat -s' reports: 2168697753 cpu context switches 2266220366 device interrupts 2902880931 software interrupts 3779075897 traps 902107847 system calls now on my box: uptime = 2 days and 'vmstat -s' reports: 1155995386 cpu context switches 164577882 device interrupts 189456976 software interrupts 137007580 traps 2178434582 system calls 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 cheers. alex ___ 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
Re: chromium port causing massive I/O faults
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? adrian On 25 July 2011 05:25, Alexander Best arun...@freebsd.org wrote: hi there, i noticed that chromium, expecially in combination with nspluginwrapper and flash, is causing a lot of I/O faults. i ran 'top -mio -I -n 99' and after only ~ 4 hours of running chromium (most of the time not loading any new pages), i got the following data: last pid: 39976; load averages: 0.37, 0.26, 0.19 up 3+02:38:30 23:15:26 72 processes: 2 running, 70 sleeping Mem: 755M Active, 662M Inact, 447M Wired, 51M Cache, 212M Buf, 45M Free Swap: 10G Total, 159M Used, 10G Free, 1% Inuse PID UID VCSW IVCSW READ WRITE FAULT TOTAL PERCENT COMMAND 39908 1001 7409 51112 0 0 4 4 0.00% /usr/local/lib/nspluginwrapper/i386/linux/npviewer.bin --plugi 39605 1001 598315 233115 11 0 3 14 0.01% /usr/local/lib/nspluginwrapper/i386/linux/npviewer.bin --plugi 1752 1001 22292378 29644471 138 0 696 834 0.38% /usr/local/bin/Xorg -nolisten inet6 1756 1001 1551733 2002630 480 0 455 935 0.43% /usr/local/bin/awesome 39140 1001 10672291 1240670 0 0 6522 6522 2.97% chrome: --type=zygote (chrome) 39116 1001 5967965 3237798 8249 20401 136394 165044 75.14% chromium-browser: (chrome) 39138 1001 6436642 994546 0 0 1785 1785 0.81% chrome: --type=zygote (chrome) 39135 1001 4334272 169320 0 0 1723 1723 0.78% chrome: --type=zygote (chrome) 39133 1001 4321593 169574 1 0 1717 1718 0.78% chrome: --type=zygote (chrome) 39132 1001 4292029 164913 6 0 1766 1772 0.81% chrome: --type=zygote (chrome) 39137 1001 4152284 139225 1 0 1762 1763 0.80% chrome: --type=zygote (chrome) 1629 560 356784 70399 25 0 40 65 0.03% /usr/local/sbin/hald 1767 1001 355603 87998 32 0 0 32 0.01% /usr/local/libexec/gam_server 39144 1001 2659919 409841 0 0 3578 3578 1.63% chrome: --type=plugin --plugin-path=/usr/home/arundel/.mozill 10217 1001 472898 258689 601 1 8 610 0.28% /usr/local/bin/musicpd /usr/local/etc/musicpd.conf 39121 1001 552140 44286 1 0 181 182 0.08% chrome: --type=zygote (chrome) 39358 1001 103237 20357 223 1479 211 1913 0.87% /usr/local/bin/sakura 39119 1001 91173 58899 2 0 14795 14797 6.74% chrome: --type=zygote (chrome) 39846 1001 275524 51575 0 0 7085 7085 3.23% chrome: --type=zygote (chrome) 39120 1001 60470 18204 0 0 22 22 0.01% chrome: --type=zygote (chrome) 1538 0 53910 6390 0 0 1 1 0.00% sendmail: accepting connections (sendmail) 39363 1001 33822 9157 1 1113 3 1117 0.51% /usr/local/bin/sakura 39805 1001 55542 43060 0 0 2787 2787 1.27% chrome: --type=zygote (chrome) 39117 1001 2935 13041 156 0 155 311 0.14% chromium-browser: (chrome) 39902 1001 43829 31005 0 0 4477 4477 2.04% chrome: --type=zygote (chrome) 362 0 28923 1878 1 0 5 6 0.00% /usr/sbin/wpa_supplicant -s -B -i wlan0 -c /etc/wpa_supplicant 1548 0 5122 672 11 0 0 11 0.01% /usr/sbin/cron -s 1217 0 13118 676 21 39 0 60 0.03% /usr/sbin/syslogd -s 39907 1001 16179 6366 0 0 2 2 0.00% /usr/local/lib/nspluginwrapper/i386/linux/npviewer.bin --plugi 39118 1001 976 716 90 0 81 171 0.08% chrome: --type=zygote (chrome) 1345 0 1362 201 1 0 2 3 0.00% /usr/local/sbin/smartd -p /var/run/smartd.pid -c /usr/local/et 1685 1001 180 22 52 0 30 82 0.04% -zsh (zsh) 1458 65534 512 62 2 0 0 2 0.00% /usr/local/bin/mpdscribble --daemon-user nobody 39360 1001 394 287 14 0 5 19 0.01% /usr/local/bin/zsh 1636 0 184 181 8 0 0 8 0.00% hald-runner 39365 1001 98 113 18 0 0 18 0.01% /usr/local/bin/zsh 1633 0 648 133 29 0 5 34 0.02% /usr/local/libexec/polkitd 1631 0 608 71 15 0 24 39 0.02% /usr/local/sbin/console-kit-daemon --no-daemon 39931 1001 53 81 1 0 1 2 0.00% /usr/local/bin/zsh 1713 1001 21 16 0 0 2 2 0.00% ssh-agent 1352 556 176
Re: chromium port causing massive I/O faults
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. ___ 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
Re: chromium port causing massive I/O faults
Same here. I have no way of sending my dump as I'm leaving for OScon and have no access to my desktop, but I did see this behavior. I'm also running HEAD on amd64. Cheers, Norberto On Jul 24, 2011, at 2:25 PM, Alexander Best wrote: hi there, i noticed that chromium, expecially in combination with nspluginwrapper and flash, is causing a lot of I/O faults. i ran 'top -mio -I -n 99' and after only ~ 4 hours of running chromium (most of the time not loading any new pages), i got the following data: last pid: 39976; load averages: 0.37, 0.26, 0.19 up 3+02:38:30 23:15:26 72 processes: 2 running, 70 sleeping Mem: 755M Active, 662M Inact, 447M Wired, 51M Cache, 212M Buf, 45M Free Swap: 10G Total, 159M Used, 10G Free, 1% Inuse PIDUID VCSW IVCSW READ WRITE FAULT TOTAL PERCENT COMMAND 39908 1001 7409 51112 0 0 4 4 0.00% /usr/local/lib/nspluginwrapper/i386/linux/npviewer.bin --plugi 39605 1001 598315 233115 11 0 3 14 0.01% /usr/local/lib/nspluginwrapper/i386/linux/npviewer.bin --plugi 1752 1001 22292378 29644471138 0696834 0.38% /usr/local/bin/Xorg -nolisten inet6 1756 1001 1551733 2002630480 0455935 0.43% /usr/local/bin/awesome 39140 1001 10672291 1240670 0 0 6522 6522 2.97% chrome: --type=zygote (chrome) 39116 1001 5967965 3237798 8249 20401 136394 165044 75.14% chromium-browser: (chrome) 39138 1001 6436642 994546 0 0 1785 1785 0.81% chrome: --type=zygote (chrome) 39135 1001 4334272 169320 0 0 1723 1723 0.78% chrome: --type=zygote (chrome) 39133 1001 4321593 169574 1 0 1717 1718 0.78% chrome: --type=zygote (chrome) 39132 1001 4292029 164913 6 0 1766 1772 0.81% chrome: --type=zygote (chrome) 39137 1001 4152284 139225 1 0 1762 1763 0.80% chrome: --type=zygote (chrome) 1629560 356784 70399 25 0 40 65 0.03% /usr/local/sbin/hald 1767 1001 355603 87998 32 0 0 32 0.01% /usr/local/libexec/gam_server 39144 1001 2659919 409841 0 0 3578 3578 1.63% chrome: --type=plugin --plugin-path=/usr/home/arundel/.mozill 10217 1001 472898 258689601 1 8610 0.28% /usr/local/bin/musicpd /usr/local/etc/musicpd.conf 39121 1001 552140 44286 1 0181182 0.08% chrome: --type=zygote (chrome) 39358 1001 103237 20357223 1479211 1913 0.87% /usr/local/bin/sakura 39119 100191173 58899 2 0 14795 14797 6.74% chrome: --type=zygote (chrome) 39846 1001 275524 51575 0 0 7085 7085 3.23% chrome: --type=zygote (chrome) 39120 100160470 18204 0 0 22 22 0.01% chrome: --type=zygote (chrome) 1538 053910 6390 0 0 1 1 0.00% sendmail: accepting connections (sendmail) 39363 100133822 9157 1 1113 3 1117 0.51% /usr/local/bin/sakura 39805 100155542 43060 0 0 2787 2787 1.27% chrome: --type=zygote (chrome) 39117 1001 2935 13041156 0155311 0.14% chromium-browser: (chrome) 39902 100143829 31005 0 0 4477 4477 2.04% chrome: --type=zygote (chrome) 362 028923 1878 1 0 5 6 0.00% /usr/sbin/wpa_supplicant -s -B -i wlan0 -c /etc/wpa_supplicant 1548 0 5122672 11 0 0 11 0.01% /usr/sbin/cron -s 1217 013118676 21 39 0 60 0.03% /usr/sbin/syslogd -s 39907 100116179 6366 0 0 2 2 0.00% /usr/local/lib/nspluginwrapper/i386/linux/npviewer.bin --plugi 39118 1001 976716 90 0 81171 0.08% chrome: --type=zygote (chrome) 1345 0 1362201 1 0 2 3 0.00% /usr/local/sbin/smartd -p /var/run/smartd.pid -c /usr/local/et 1685 1001 180 22 52 0 30 82 0.04% -zsh (zsh) 1458 65534 512 62 2 0 0 2 0.00% /usr/local/bin/mpdscribble --daemon-user nobody 39360 1001 394287 14 0 5 19 0.01% /usr/local/bin/zsh 1636 0 184181 8 0 0 8 0.00% hald-runner 39365 1001 98113 18 0 0 18 0.01% /usr/local/bin/zsh 1633 0 648133 29 0 5 34 0.02% /usr/local/libexec/polkitd 1631 0 608 71 15 0 24 39 0.02% /usr/local/sbin/console-kit-daemon --no-daemon 39931 1001 53 81 1 0 1 2 0.00% /usr/local/bin/zsh 1713 1001 21 16 0 0 2 2 0.00% ssh-agent 1352556 176125 2 0 0 2 0.00% /usr/local/bin/dbus-daemon --system
Re: chromium port causing massive I/O faults
Am 24.07.2011 23:25, schrieb Alexander Best: hi there, i noticed that chromium, expecially in combination with nspluginwrapper and flash, is causing a lot of I/O faults. i ran 'top -mio -I -n 99' and after It's causing page faults, which is a massive difference. only ~ 4 hours of running chromium (most of the time not loading any new pages), i got the following data: last pid: 39976; load averages: 0.37, 0.26, 0.19 up 3+02:38:30 23:15:26 72 processes: 2 running, 70 sleeping Mem: 755M Active, 662M Inact, 447M Wired, 51M Cache, 212M Buf, 45M Free Swap: 10G Total, 159M Used, 10G Free, 1% Inuse ... is anybody else experiencing the same behavior? i also noticed a massive fault burst (~ 1500/sec), when closing chromium. Is that special to Chrome or -CURRENT? Or does it also happen with Firefox, for instance, or on -STABLE? I suppose FF might cause even more, it readily consumes 1.5 GB on my Linux computer after some time running. A page fault affecting 1500 pages/s (note it's s NOT sec!) amounts to 6 MB/s which appears to be on the comfortable side for any halfway modern system. Page in/page out is quite normal behaviour for any system that has swap space available and is running (especially idle) applications with nontrivial memory requirements and ultimately filling up its ram. At some point in time, when applications have been idle for long enough, it's more useful to page out unused pages and use them as cache instead. Why would a swap usage of 8% of physical RAM size be a reason for concern on a 2 GB RAM 64-bit computer? ___ 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
Re: chromium port causing massive I/O faults
Is it perhaps doing disk IO using mmap? adrian On 25 July 2011 05:25, Alexander Best arun...@freebsd.org wrote: hi there, i noticed that chromium, expecially in combination with nspluginwrapper and flash, is causing a lot of I/O faults. i ran 'top -mio -I -n 99' and after only ~ 4 hours of running chromium (most of the time not loading any new pages), i got the following data: last pid: 39976; load averages: 0.37, 0.26, 0.19 up 3+02:38:30 23:15:26 72 processes: 2 running, 70 sleeping Mem: 755M Active, 662M Inact, 447M Wired, 51M Cache, 212M Buf, 45M Free Swap: 10G Total, 159M Used, 10G Free, 1% Inuse PID UID VCSW IVCSW READ WRITE FAULT TOTAL PERCENT COMMAND 39908 1001 7409 51112 0 0 4 4 0.00% /usr/local/lib/nspluginwrapper/i386/linux/npviewer.bin --plugi 39605 1001 598315 233115 11 0 3 14 0.01% /usr/local/lib/nspluginwrapper/i386/linux/npviewer.bin --plugi 1752 1001 22292378 29644471 138 0 696 834 0.38% /usr/local/bin/Xorg -nolisten inet6 1756 1001 1551733 2002630 480 0 455 935 0.43% /usr/local/bin/awesome 39140 1001 10672291 1240670 0 0 6522 6522 2.97% chrome: --type=zygote (chrome) 39116 1001 5967965 3237798 8249 20401 136394 165044 75.14% chromium-browser: (chrome) 39138 1001 6436642 994546 0 0 1785 1785 0.81% chrome: --type=zygote (chrome) 39135 1001 4334272 169320 0 0 1723 1723 0.78% chrome: --type=zygote (chrome) 39133 1001 4321593 169574 1 0 1717 1718 0.78% chrome: --type=zygote (chrome) 39132 1001 4292029 164913 6 0 1766 1772 0.81% chrome: --type=zygote (chrome) 39137 1001 4152284 139225 1 0 1762 1763 0.80% chrome: --type=zygote (chrome) 1629 560 356784 70399 25 0 40 65 0.03% /usr/local/sbin/hald 1767 1001 355603 87998 32 0 0 32 0.01% /usr/local/libexec/gam_server 39144 1001 2659919 409841 0 0 3578 3578 1.63% chrome: --type=plugin --plugin-path=/usr/home/arundel/.mozill 10217 1001 472898 258689 601 1 8 610 0.28% /usr/local/bin/musicpd /usr/local/etc/musicpd.conf 39121 1001 552140 44286 1 0 181 182 0.08% chrome: --type=zygote (chrome) 39358 1001 103237 20357 223 1479 211 1913 0.87% /usr/local/bin/sakura 39119 1001 91173 58899 2 0 14795 14797 6.74% chrome: --type=zygote (chrome) 39846 1001 275524 51575 0 0 7085 7085 3.23% chrome: --type=zygote (chrome) 39120 1001 60470 18204 0 0 22 22 0.01% chrome: --type=zygote (chrome) 1538 0 53910 6390 0 0 1 1 0.00% sendmail: accepting connections (sendmail) 39363 1001 33822 9157 1 1113 3 1117 0.51% /usr/local/bin/sakura 39805 1001 55542 43060 0 0 2787 2787 1.27% chrome: --type=zygote (chrome) 39117 1001 2935 13041 156 0 155 311 0.14% chromium-browser: (chrome) 39902 1001 43829 31005 0 0 4477 4477 2.04% chrome: --type=zygote (chrome) 362 0 28923 1878 1 0 5 6 0.00% /usr/sbin/wpa_supplicant -s -B -i wlan0 -c /etc/wpa_supplicant 1548 0 5122 672 11 0 0 11 0.01% /usr/sbin/cron -s 1217 0 13118 676 21 39 0 60 0.03% /usr/sbin/syslogd -s 39907 1001 16179 6366 0 0 2 2 0.00% /usr/local/lib/nspluginwrapper/i386/linux/npviewer.bin --plugi 39118 1001 976 716 90 0 81 171 0.08% chrome: --type=zygote (chrome) 1345 0 1362 201 1 0 2 3 0.00% /usr/local/sbin/smartd -p /var/run/smartd.pid -c /usr/local/et 1685 1001 180 22 52 0 30 82 0.04% -zsh (zsh) 1458 65534 512 62 2 0 0 2 0.00% /usr/local/bin/mpdscribble --daemon-user nobody 39360 1001 394 287 14 0 5 19 0.01% /usr/local/bin/zsh 1636 0 184 181 8 0 0 8 0.00% hald-runner 39365 1001 98 113 18 0 0 18 0.01% /usr/local/bin/zsh 1633 0 648 133 29 0 5 34 0.02% /usr/local/libexec/polkitd 1631 0 608 71 15 0 24 39 0.02% /usr/local/sbin/console-kit-daemon --no-daemon 39931 1001 53 81 1 0 1 2 0.00% /usr/local/bin/zsh 1713 1001 21 16 0 0 2 2 0.00% ssh-agent 1352 556 176 125 2 0 0 2 0.00% /usr/local/bin/dbus-daemon --system 1494 0 62 17 45 0 14 59 0.03% /usr/local/sbin/cupsd -C
