在高磁盘I / O期间提高系统性能/响应能力方面有什么进展？

只要有高磁盘I / O，系统就会比平时慢得多并且响应速度也较慢。Linux内核对此有何进展？这个问题正在积极地解决吗？

我认为大部分已解决。在繁重的IO下，我的性能在2.6.36中有所改善，我希望在2.6.37中有更多的改善。请参阅这些 phononix文章。

Wu Fengguang和KOSAKI Motohiro本周发布了补丁程序，他们相信这些补丁程序将解决其中的一些响应性问题，他们称其为“系统在内存压力和大量脏页/回写页下无法响应”错误。用户Andreas Mohr是向LKML报告此问题并测试了针对内核vmscan报告的两个补丁的用户之一。Andreas的问题是，当通过USB 1.1连接固态驱动器时，制作EXT4文件系统时，系统变得完全无响应（并且切换到VT需要20秒钟以上）。在他的系统上，从/ dev / zero文件写入300M时，问题更加严重。

这是错误的直接链接

同样来自凤凰

幸运的是，从我们的测试以及其他希望纠正此问题的Linux用户的报告来看，发布的相对较小的vmscan补丁似乎确实可以更好地解决该问题。如果系统正在承受大量磁盘活动，则用户界面（在我们的例子中为GNOME）仍然不是100％流畅，但是它肯定比以前好得多，甚至在Linux 2.6.35内核中也能找到。

还有Phoronix 2.6.36的发布公告

似乎障碍物正在消失，这也应该有助于提高性能。

在实践中，壁垒在杀死块I / O性能方面具有令人不快的声誉，以至于管理员经常倾向于关闭壁垒并承担风险。虽然由现代硬件提供的标记队列操作应该可以很好地实现障碍，但是尝试利用这些功能通常会遇到困难。因此，在现实世界中，屏障是通过在发出屏障操作之前简单地清空I / O请求队列来实现的，并加入了一些刷新操作以使硬件将数据实际提交到持久性介质。排空操作将使设备停滞并终止充分发挥性能所需的并行性。使用障碍可能会很痛苦，这也就不足为奇了。

还有关于公平I / O调度的LWN文章

我想说IO对于2.6.28中ext4的发布时间来说意义重大。以下链接指向Linux Kernel Newbies Kernel发行版，您应该查看Block和Filesystems部分。当然，这可能是不公平的看法，或者只是在我开始关注FS开发时，我确信它一直在改善，但是我感觉到ext4的某些问题，“导致人们不得不认真考虑IO堆栈，或者可能是因为他们希望ext4解决所有性能问题，然后当他们没有意识到时，他们意识到他们不得不在其他地方寻找问题。

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