Responsiveness under disk I/O

Posted Nov 18, 2010 15:33 UTC (Thu) by Cato (guest, #7643)
Parent article: TTY-based group scheduling

I think the real problem still to be solved is responsiveness under I/O as in https://bugzilla.kernel.org/show_bug.cgi?id=12309 - I find that large apps such as VMware and Firefox can cause keyboard input to freeze for many seconds using kernel 2.6.24 and Ubuntu 8.04, which should be a reliable combination by now.

Probably it's a VM issue, but it's hard to understand why Linux can't keep up with my typing these days given much faster hardware, when it always used to back in the days of formatting floppy disks in background.

Firefox is a key issue - with 100-200 tabs this freezing of keyboard input across the whole system is much more frequent, and "pidstat -d 5" shows that it and kjournald are doing some I/O, though at quite low rates. This is on a Core 2 Duo system with 4 GB RAM and PAE enabled, and about 50% of RAM used by programs typically.

Linux always used to be stunningly fast and responsive compared to Windows - with bugs like this, and the choice of a lumbering Firefox vs. a Chrome that lacks key extensions, it's still not quite there as a desktop. My main desktop is still Linux but I'd really like it to perform more consistently.

to post comments

Responsiveness under disk I/O

Posted Nov 18, 2010 16:42 UTC (Thu) by vgoyal (guest, #49279) [Link]

There are close to 500 comments in the bz. So I have not read it yet. Can you just tell a quick summary about what is happening. IOW, here one person has to be doing lots of IO behind which other IO gets delayed. So in this case is it VM or firefox which is doing lots of buffered WRITES or direct WRITES or what. Some blktracing might help.

You also might want to play a bit with blkio cgroup controller. Try putting firefox/VM in a separate cgroup or try putting your terminal in a separate cgroup and see if it helps.

For further information look at Documentation/cgroups/blkio-controller.txt

Responsiveness under disk I/O

Posted Nov 18, 2010 21:33 UTC (Thu) by clugstj (subscriber, #4020) [Link] (2 responses)

100-200 tabs in Firefox? I don't really think Firefox was designed for that.

Responsiveness under disk I/O

Posted Nov 19, 2010 12:03 UTC (Fri) by Cato (guest, #7643) [Link] (1 responses)

You're probably right, but since I keep Firefox open for weeks with session recovery enabled, it's quite easy to build up to that. It's also a good way to stress a Linux system, and I have similar tab counts on Windows 7 which doesn't exhibit this intermittent system-wide pause/freeze behaviour (as long as I don't let it page too much).

I'm experimenting with a very small swapfile on Linux (512MB) etc but that hasn't solved this.

Responsiveness under disk I/O

Posted Nov 26, 2010 9:11 UTC (Fri) by jospoortvliet (guest, #33164) [Link]

Don't worry, you don't need 200 tabs in Firefox to get this behavior. I get it all the time by just running a few more apps than (apparently) the kernel with this hardware can handle. Often - memory at 50%, cpu low, but IO spikes up and typing an email is going back to the '80s with having to wait +5 sec for each character to appear. Embarasing, considering I have little if anything running that requires real resources or IO (mail, chat, feedreader, few browser windows, text editor, filemanager, calendar - that's it).