I retried my 2.8GB copy tests on the -generic kernel after manually switching to deadline scheduling and back to cfq, and for me the desktop is definitely more responsive under deadline (note: I didn't try writeback or any other settings, just the scheduling).
In one test with deadline scheduling firefox didn't grey out at all, and in another it greyed out twice but only for half a second or so (and nautilus greyed out once for a couple of seconds). With cfq, firefox was greying out for five to ten seconds at a time. Irrespective of which scheduling I choose, the average throughput reported by nautilus is the same. Thanks to Anil, Tobias, and Ravindran for the info about how to change the scheduling. @Thomas Pi: I actually don't normally have problems with vmware-server 1.05 (XP runs at a similar speed to natively), but I find that occasionally the VM will get itself into a state where it thrashes the disk whenever I try to do something (even scrolling), and at this point it becomes unusable like you say. Sometimes vmware-server does this when I first boot the VM, in which case it takes forever to boot. Whenever it happens, a power reset from the VMWare menu fixes the problem. So maybe there's a separate bug in vmware that is making it look like this bug? -- Heavy Disk I/O harms desktop responsiveness https://bugs.launchpad.net/bugs/131094 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
