New KTR trace for mouse freezing/stuttering in 7.0-RC1
John Baldwin
jhb at freebsd.org
Fri Jan 25 06:39:36 PST 2008
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
More information about the freebsd-stable
mailing list