From owner-freebsd-current@FreeBSD.ORG Thu Jul 28 20:03:07 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id B99781065678; Thu, 28 Jul 2011 20:03:07 +0000 (UTC) Date: Thu, 28 Jul 2011 20:03:07 +0000 From: Alexander Best To: =?iso-8859-15?Q?Ren=E9?= Ladan Message-ID: <20110728200307.GA65254@freebsd.org> References: <20110724212544.GA57733@freebsd.org> <20110725072102.GA24938@freebsd.org> <4E2D2C32.5010602@gmx.de> <20110727004850.GA63109@freebsd.org> <20110727083339.GA12233@tops> <20110727092338.GA10526@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Cc: Norberto Lopes , Gleb Kurtsou , Matthias Andree , Adrian Chadd , freebsd-current@freebsd.org Subject: Re: chromium port causing massive I/O faults X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2011 20:03:07 -0000 On Wed Jul 27 11, René Ladan wrote: > 2011/7/27 Alexander Best : > > On Wed Jul 27 11, René Ladan wrote: > >> 2011/7/27 Gleb Kurtsou : > >> > 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(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@ 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/ > >