Re: chromium port causing massive I/O faults

From: Alexander Best <arundel_at_freebsd.org>
Date: Thu, 28 Jul 2011 20:03:07 +0000
On Wed Jul 27 11, René Ladan wrote:
> 2011/7/27 Alexander Best <arundel_at_freebsd.org>:
> > On Wed Jul 27 11, René Ladan wrote:
> >> 2011/7/27 Gleb Kurtsou <gleb.kurtsou_at_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_at_.
> >> > 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(0x7fffff7f9630,0x7fffff7f9640)
> >> >  12747 chrome   15.077396 CALL  clock_gettime(0x4,0x7fffffbfb6f0)
> >> >  12747 chrome   15.077497 CALL  gettimeofday(0x7fffffbfb650,0x7fffffbfb660)
> >> >  12747 chrome   15.077609 CALL  gettimeofday(0x7fffffbfb650,0x7fffffbfb660)
> >> >  12747 chrome   15.077723 CALL  gettimeofday(0x7fffffbfb650,0)
> >> >  12747 chrome   15.077845 CALL  clock_gettime(0,0x7fffffbfb2b0)
> >> >  12747 chrome   15.078337 CALL  clock_gettime(0x4,0x7fffff9fa630)
> >> >  12747 chrome   15.078544 CALL  clock_gettime(0x4,0x7fffff9fa650)
> >> >  12747 chrome   15.078587 CALL  clock_gettime(0x4,0x7fffff9fa650)
> >> >  12747 chrome   15.078632 CALL  clock_gettime(0x4,0x7fffff9fa650)
> >> >  12747 chrome   15.078674 CALL  clock_gettime(0x4,0x7fffff9fa650)
> >> >  12747 chrome   15.082803 CALL  gettimeofday(0x7ffffedd3630,0x7ffffedd3640)
> >> >  12747 chrome   15.084644 CALL  gettimeofday(0x7fffffbfb650,0x7fffffbfb660)
> >> >  12747 chrome   15.084746 CALL  clock_gettime(0x4,0x7fffffbfb670)
> >> >  12747 chrome   15.084815 CALL  clock_gettime(0x4,0x7fffffbfb670)
> >> >  12747 chrome   15.086620 CALL  gettimeofday(0x7ffffefd4650,0x7ffffefd4660)
> >> >  12747 chrome   15.086736 CALL  clock_gettime(0x4,0x7ffffefd4670)
> >> >  12747 chrome   15.086815 CALL  clock_gettime(0x4,0x7ffffefd4670)
> >> >  12747 chrome   15.098315 CALL  gettimeofday(0x7fffffffafe0,0x7fffffffaff0)
> >> >  12747 chrome   15.098680 CALL  clock_gettime(0x4,0x7fffffffb250)
> >> >
> >> > Some work was done by kib_at_ 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/
> >
Received on Thu Jul 28 2011 - 18:03:07 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:16 UTC