Re: New KTR trace for mouse freezing/stuttering in 7.0-RC1
On Friday 25 January 2008 05:31:34 pm Joe Peterson wrote: John Baldwin wrote: Hmm, when I look at that graph using schedgraphy from HEAD it just looks like xtrs is using up all the CPU. Yeah, xtrs is eating a lot of CPU, but I've never seen this affect the mouse movement (making it really jerky) the same way on, e.g., Linux. And the xtrs test is just a way to *reliably* make it happen. It happens intermittently all of the time (at least every few minutes, and often in small batches) even when the system is pretty idle... -Joe So it's a scheduling bug where a compute bound process is starving an interactive one basically. :) Since you are using ULE, I would try talking to Jeff (jeff@) to see if he can address this. -- John Baldwin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: New KTR trace for mouse freezing/stuttering in 7.0-RC1
Sam Leffler wrote: 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. No problem, Sam, but the question I have for you now is: do you see anything with the updated schedgraph that indicates any freezes that look funny? The length of the ones I saw with mouse movement were mostly some portion of a second, from maybe 1/8 to 1/2 sec. And there should be a lot of them in quick succession. Thanks, Joe ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: New KTR trace for mouse freezing/stuttering in 7.0-RC1
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 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: New KTR trace for mouse freezing/stuttering in 7.0-RC1
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 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: New KTR trace for mouse freezing/stuttering in 7.0-RC1
John Baldwin wrote: Hmm, when I look at that graph using schedgraphy from HEAD it just looks like xtrs is using up all the CPU. Yeah, xtrs is eating a lot of CPU, but I've never seen this affect the mouse movement (making it really jerky) the same way on, e.g., Linux. And the xtrs test is just a way to *reliably* make it happen. It happens intermittently all of the time (at least every few minutes, and often in small batches) even when the system is pretty idle... -Joe ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: New KTR trace for mouse freezing/stuttering in 7.0-RC1
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. Have you tried not touching the mouse playing mp3 music do you also hear sound interruptions after a few minutes ? As well as the people talking re. mouse (BTW Kris asked current@ recently if anyone had time to look at Giant lock); Others hear sound interruptions: I wonder if there may be some commonality as well as/beyond mouse locking, in scheduling/locking etc. I've heard sound interuptions on kernels with both schedulers, (but my hosts are sensitive as slow with DMA off (else wont boot), I must review my configs some more). -- Julian Stacey. Munich Computer Consultant, BSD Unix C Linux. http://berklix.com ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: New KTR trace for mouse freezing/stuttering in 7.0-RC1
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. Sam ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: New KTR trace for mouse freezing/stuttering in 7.0-RC1
Sam Leffler wrote: http://www.skyrush.com/downloads/ktr_ule_4.out 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. OK, I just ran a dmesg and put it up there: http://www.skyrush.com/downloads/dmesg_4.out The WRITE_DMA messages are not time-correlated with this issue; I don't like the looks of those either, but that's a different issue to look into... Also if you rebuild the kernel the kernel with DIAGNOSTIC then softclock() will complain about callouts that take longer than 2ms to run. OK, recompiling now... Will the new messages appear in dmesg, or in a log file? This might generate too much noise in which case you can adjust the threshold by editing the code in sys/kern/kern_timeout.c. Cool - thanks for looking at this, and I will let you know what I find! Do I need to make another trace concurrently, or should I just repeat the test procedure and see if I get new messages? -Thanks, Joe ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
