Doh! Now that I'm no longer using the 8 month old version of schedgraph.py that was displaying interesting but useless graphs, perhaps I won't continue to appear as though I'm raving like such a lunatic about what is contained in my ktr captures.
Here follows a re-examination of the previously posted data with a recent schedgraph.py. Note that lacking any particular knowledge I'm only guessing at what might be significant. http://au.dyndns.ws/public/ktr-sched_gnome-netmonitor.out.bz2 (Stutter in glxgears with gnome metwork monitor) glxgears in runq for 236ms http://au.dyndns.ws/public/ktr-sched_move-glxgears_1.out.bz2 http://au.dyndns.ws/public/ktr-sched_move-glxgears_2.out.bz2 Nothing significant is apparent. http://au.dyndns.ws/public/ktr-sched_move-glxgears_3.out.bz2 (Dragging glxgears window which freezes - stops following mouse and stops updating, desktop doesn't respond to keyboard/mouse-clicks for the duration) glxgears in runq for 278ms and almost immediately again for 381ms. Note that this doesn't capture the entire period of interest which can be 1-2 seconds, due to the high number of context switches occurring with glxgears running and the difficulty of stopping the logging quickly after the event. I'll need a much larger (than 128k) buffer to catch an event in its entirety, unless someone can suggest a way to reduce the number of context switches significantly? http://au.dyndns.ws/public/ktr-sched-200801192346.out.bz2 Looks like this was probably just a mouse disconnect/reconnect - there is approx 1s of inactivity in irq20/ohci0 towards the end. Unfortunately these disconnects occur very frequently (typically multiple times per hour) since running with the KTR-enabled kernel (afaict). Unfortunately it looks as though that after gaining a false impression from this capture with the old schedgraph.py, I subsequently mis-interpreted numerous mouse disconnects as desktop freeze events. http://au.dyndns.ws/public/ktr-sched-200801200336.out.bz2 Looks like just another mouse disconnect. http://au.dyndns.ws/public/ktr-sched-200801200302.out.bz2 http://au.dyndns.ws/public/ktr-sched-200801210207.out.bz2 Nothing interesting is apparent. So it seems the only thing of interest that I"ve managed to capture so far pertains to glxgears - an instance of the "stutter" and a part of a short freeze when dragging its window. Unfortunately these frequent mouse disconnects make it difficult to recognise genuine freezes during 'normal' use, if indeed they are still occurring with RELENG_7. However the glxgears behaviour remains (apparently) the same as it was on RELENG_6. Whether that's a telling sign or not remains to be seen. Wayne _______________________________________________ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"