measuring desktop responsiveness?
I'm one of many who are affected by kernel bug 12309 ( http://bugzilla.kernel.org/show_bug.cgi?id=12309 ) and as you can see, the major symptom is that desktop responsivness taking a hit during heavy I/O operations. Thing is, there is no way to measure desktop responsiveness objectively that I know of. Could it be possible to see PTS to include such a test in the future? it would be quite helpful and useful for future usage i'm sure
I have an idea for possibly making an automated test of this... Will check when I am back in the office.
Maybe you should try 2.6.30-rc3, because there are "some block IO scheduling fixes". Btw. is this bug confirmed by kernel devs? As I remember there was something about this or similar issue at lkml, but it wasn't really bug. What fs are you using? You suffer from this bug doing what operations? Are you using FUSE?
Originally Posted by KhaaL
Last edited by kraftman; 04-22-2009 at 05:35 PM.
Great, I'm looking forward to try this out!
Originally Posted by Michael
Thanks for the suggestions. This bug is hard to confirm by the devs - or rather its hard to confirm the cause of the bug. so far I've experienced it on ext3, ext4 and reiserFS without any use of FUSE. I'll try .30-rc3 as soon nvidia release a driver compatible with it :-)
Originally Posted by kraftman
Nvidia 180.53 works with 2.6.30.
There is a test case which makes it possible to measure the desktop responsiveness latencies.
The problem is, that this bug is not deterministic. You can create heavy io without notice the bug, but mostly there is the poor desktop responsiveness.
See the three test results of 2.6.29 or 2.6.30-rc2-smp in the result log.
I have the same issue with a box using XFS, I found it kind-of unexplainable, but going though that bug it makes sense now
Maybe only CFQ is affected? Does someone tried with another scheduler? And maybe it's already fixed in 2.6.30-rc3:
Originally Posted by grigi
Last edited by kraftman; 04-23-2009 at 02:44 PM.
This bug exists since 2.6.18 or even earlier. The real cause is unknowns. There were many tries to fix this bug in ext3 implementation, block layer, io scheduler or event cpu scheduler, without real improvements.
bug in bugzilla
bug in ubuntu's launchpad