From owner-freebsd-current@FreeBSD.ORG Wed Jul 27 09:38:57 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id 089261065783; Wed, 27 Jul 2011 09:38:57 +0000 (UTC) Date: Wed, 27 Jul 2011 09:38:57 +0000 From: Alexander Best To: =?iso-8859-15?Q?Ren=E9?= Ladan Message-ID: <20110727093857.GA12549@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: Wed, 27 Jul 2011 09:38:57 -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. ...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% per-directory deletions 2%, falsehits 0%, toolong 0% with chromium running: otaku% vmstat -s|grep "context switches"; sleep 1; vmstat -s|grep "context switches" 39604188 cpu context switches 39610679 cpu context switches without: otaku% vmstat -s|grep "context switches"; sleep 1; vmstat -s|grep "context switches" 39722188 cpu context switches 39722998 cpu context switches cheers. alex > >> > > >> > 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/ > >