Date: Fri, 25 Jan 2008 09:37:21 -0500 From: John Baldwin <jhb@freebsd.org> To: freebsd-stable@freebsd.org Cc: Joe Peterson <joe@skyrush.com> Subject: Re: New KTR trace for mouse freezing/stuttering in 7.0-RC1 Message-ID: <200801250937.22051.jhb@freebsd.org> In-Reply-To: <47987511.6070201@errno.com> References: <1199812249.96494.133.camel@predator-ii.buffyverse> <47981DC7.2030706@skyrush.com> <47987511.6070201@errno.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200801250937.22051.jhb>