From owner-freebsd-stable@FreeBSD.ORG Fri Jan 25 20:46:27 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 6272516A419; Fri, 25 Jan 2008 20:46:27 +0000 (UTC) (envelope-from sam@errno.com) Received: from ebb.errno.com (ebb.errno.com [69.12.149.25]) by mx1.freebsd.org (Postfix) with ESMTP id 172B313C45A; Fri, 25 Jan 2008 20:46:26 +0000 (UTC) (envelope-from sam@errno.com) Received: from trouble.errno.com (trouble.errno.com [10.0.0.248]) (authenticated bits=0) by ebb.errno.com (8.13.6/8.12.6) with ESMTP id m0PKkQ8A037957 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 25 Jan 2008 12:46:26 -0800 (PST) (envelope-from sam@errno.com) Message-ID: <479A4AA2.9020408@errno.com> Date: Fri, 25 Jan 2008 12:46:26 -0800 From: Sam Leffler User-Agent: Thunderbird 2.0.0.9 (X11/20071125) MIME-Version: 1.0 To: John Baldwin References: <1199812249.96494.133.camel@predator-ii.buffyverse> <47981DC7.2030706@skyrush.com> <47987511.6070201@errno.com> <200801250937.22051.jhb@freebsd.org> In-Reply-To: <200801250937.22051.jhb@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-DCC-sonic.net-Metrics: ebb.errno.com; whitelist Cc: Joe Peterson , freebsd-stable@freebsd.org 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 20:46:27 -0000 John Baldwin wrote: > 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. > Sigh, you are correct. I backrev'd the machine where I ran schedgraph to RELENG_7 and didn't notice the old version mis-parses the ktr file. The graph is totally different w/ schedgraph from HEAD. Sorry Joe for misleading you. Sam