Linux Performance – Improving System Performance During High Disk I/O

iokernellinuxperformance

Whenever there is high disk I/O, the system tends to be much slower and less responsive than usual. What's the progress on Linux kernel regarding this? Is this problem actively being worked on?

Best Answer

I think for the most part it has been solved. My performance under heavy IO has improved in 2.6.36 and I expect it to improve more in 2.6.37. See these phoronix Articles.

Wu Fengguang and KOSAKI Motohiro have published patches this week that they believe will address some of these responsiveness issues, for which they call the "system goes unresponsive under memory pressure and lots of dirty / writeback pages" bug. Andreas Mohr, one of the users that has reported this problem to the LKML and tested the two patches that are applied against the kernel's vmscan reported success. Andreas' problem was the system becoming fully unresponsive (and switching to a VT took 20+ seconds) when making an EXT4 file-system when a solid-state drive was connected via USB 1.1. On his system when writing 300M from the /dev/zero file the problem was even worse.

Here's a direct link to the bug

Also from Phoronix

Fortunately, from our testing and the reports of other Linux users looking to see this problem corrected, the relatively small vmscan patches that were published do seem to better address the issue. The user-interface (GNOME in our case) still isn't 100% fluid if the system is sustaining an overwhelming amount of disk activity, but it's certainly much better than before and what's even found right now with the Linux 2.6.35 kernel.

There's also the Phoronix 2.6.36 release announcement

It seems block barriers are going away and that should also help performance.

In practice, barriers have an unpleasant reputation for killing block I/O performance, to the point that administrators are often tempted to turn them off and take their risks. While the tagged queue operations provided by contemporary hardware should implement barriers reasonably well, attempts to make use of those features have generally run into difficulties. So, in the real world, barriers are implemented by simply draining the I/O request queue prior to issuing the barrier operation, with some flush operations thrown in to get the hardware to actually commit the data to persistent media. Queue-drain operations will stall the device and kill the parallelism needed for full performance; it's not surprising that the use of barriers can be painful.

There's also this LWN article on fair I/O Scheduling

I would say IO reawakened as a big deal about the time of the release of ext4 in 2.6.28. The following links are to Linux Kernel Newbies Kernel releases, you should review the Block, and Filesystems sections. This may of course be unfair sentiment, or just the time I started watching FS development, I'm sure it's been improving all along, but I feel that some of the ext4 issues, 'caused people to look hard at the IO stack, or it might be that they were expecting ext4 to resolve all the performance issues, and then when it didn't they realized they had to look elsewhere for the problems.

2.6.28, 2.6.29, 2.6.30, 2.6.31, 2.6.32, 2.6.33, 2.6.34, 2.6.35, 2.6.36, 2.6.37

Related Question