From owner-freebsd-stable@FreeBSD.ORG Fri Jan 25 14:39:36 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 74AF116A46D for ; Fri, 25 Jan 2008 14:39:36 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 7045913C461 for ; Fri, 25 Jan 2008 14:39:36 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from zion.baldwin.cx (66-23-211-162.clients.speedfactory.net [66.23.211.162]) by elvis.mu.org (Postfix) with ESMTP id A34771A4D8C; Fri, 25 Jan 2008 06:35:35 -0800 (PST) From: John Baldwin To: freebsd-stable@freebsd.org Date: Fri, 25 Jan 2008 09:37:21 -0500 User-Agent: KMail/1.9.7 References: <1199812249.96494.133.camel@predator-ii.buffyverse> <47981DC7.2030706@skyrush.com> <47987511.6070201@errno.com> In-Reply-To: <47987511.6070201@errno.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200801250937.22051.jhb@freebsd.org> Cc: Joe Peterson Subject: Re: New KTR trace for mouse freezing/stuttering in 7.0-RC1 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jan 2008 14:39:36 -0000 On Thursday 24 January 2008 06:22:57 am Sam Leffler wrote: > Joe Peterson wrote: > > In an attempt to track down this mouse freezing/stuttering (i.e. "jerky > > mouse movement) behavior in FreeBSD 7.0-RC1, I have come up with a > > reliable way to cause it to happen, and I have created a longer trace > > showing the results. Note that I am using the ULE scheduler. > > > > In general, it becomes easier to see the effect if there is CPU > > activity. I have noticed it during kernel compiles, while at the same > > time loading web pages in firefox that contain images (and moving the > > mouse while this is happening). But a more controlled way to see it is > > to run something that uses some CPU and then generating lots of X events. > > > > In my case, I start "xtrs" (TRS-80 emulator) in Model IV mode, which > > happens to poll for input, using the CPU. Then I move the mouse back > > and forth quickly between windows in "focus under mouse" mode (in my > > case, a KDE focus mode), which causes many focus events quickly. In > > about 15 or 20 seconds, the mouse reliably starts to show erratic > > movement, not moving smoothly. > > > > I really hope this can shed more light on what might be going on. Here > > is the trace: > > > > http://www.skyrush.com/downloads/ktr_ule_4.out > > > > > > This is an interesting trace. It appears that something is blocking > threads in the runq from running for 2 seconds! I don't see what it is > from the trace data. It sort of looks like the last thing that ran is > the swi4 which is likely a callout (need to check the log file contents > to be certain). If the callback function does something it wouldn't > necessarily be visible in the schedgraph plot. If you could stick a > dmesg from booting out in the same spot it might be worthwhile. Also if > you rebuild the kernel the kernel with DIAGNOSTIC then softclock() will > complain about callouts that take longer than 2ms to run. This might > generate too much noise in which case you can adjust the threshold by > editing the code in sys/kern/kern_timeout.c. Hmm, when I look at that graph using schedgraphy from HEAD it just looks like xtrs is using up all the CPU. I didn't see the 2 second window where nothing was running. -- John Baldwin