Date: Thu, 28 Jul 2011 16:05:48 +0800 From: Adrian Chadd <adrian@freebsd.org> To: "Sean C. Farley" <scf@freebsd.org> Cc: Norberto Lopes <nlopes.ml@gmail.com>, Alexander Best <arundel@freebsd.org>, Gleb Kurtsou <gleb.kurtsou@gmail.com>, Matthias Andree <matthias.andree@gmx.de>, freebsd-current@freebsd.org Subject: Re: chromium port causing massive I/O faults Message-ID: <CAJ-VmokuBe-txQ%2B6wCSG=3Y4NKhTGzDGiNAq95D9=iuzf1pnWQ@mail.gmail.com> In-Reply-To: <alpine.BSF.2.02.1107272149390.3311@thor.farley.org> References: <20110724212544.GA57733@freebsd.org> <CAJ-VmonHcDM_p3%2BYPO2vyF9a054VavQmVQqcKt369w28M%2BtaXg@mail.gmail.com> <20110725072102.GA24938@freebsd.org> <4E2D2C32.5010602@gmx.de> <20110727004850.GA63109@freebsd.org> <20110727083339.GA12233@tops> <alpine.BSF.2.02.1107272149390.3311@thor.farley.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <scf@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. =A0Although it may sound sca= ry, 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. =A0let'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 >> =A024343 >> >> ~ % kdump -E -m 1 -f ktrace.out | grep 'CALL .*gettime' | tail -20 >> 12747 chrome =A0 15.077376 CALL =A0gettimeofday(0x7fffff7f9630,0x7fffff7= f9640) >> 12747 chrome =A0 15.077396 CALL =A0clock_gettime(0x4,0x7fffffbfb6f0) > > *snip* > >> Some work was done by kib@ to create a kernel page strong current time a= nd >> other misc info to eliminate gettimeofday kind syscalls. =A0Bits of it w= ere >> commited but I'm not sure if it was finished. =A0But 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 t= his > with Firefox (at least 4 and 5) that causes Xorg to run close to 100% whi= le > Firefox creates a new tab under certain circumstances. =A0The best exampl= e 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. =A0Xorg is busy making a large number of gettimeofday() and > clock_gettime() calls amongst other calls. > > This is with stable/8 r223876. =A0The window manager does not matter. =A0= At > least, Fluxbox and TWM exhibit this. =A0However, the size of the Firefox > window does (close to 1680x1050). =A0Also, the window must be the top win= dow > and not minimized. =A0I 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! =A0;)-- that it was Firefox > updating the title of the window incessantly as the tab is created. =A0An > interesting workaround to this tab creation issue is to set > browser.tabs.loadDivertedInBackground to True. =A0It does not fix all cas= es. > >>> 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 > -- > scf@FreeBSD.org >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJ-VmokuBe-txQ%2B6wCSG=3Y4NKhTGzDGiNAq95D9=iuzf1pnWQ>