New KTR trace for mouse freezing/stuttering in 7.0-RC1
sam at errno.com
Thu Jan 24 03:36:24 PST 2008
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:
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.
More information about the freebsd-stable