在高磁盘 I/O 期间提高系统性能/响应能力的进展如何？

Question

每当有高磁盘 I/O 时，系统往往比平时慢得多，响应也更慢。Linux内核在这方面有什么进展？是否正在积极解决这个问题？

Answer 1

我认为大部分已经解决了。我在重 IO 下的性能在 2.6.36 中得到了改善，我希望它在 2.6.37 中得到更多改善。请参阅这些 phoronix文章。

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

这是错误的直接链接

也来自 Phoronix

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

还有Phoronix 2.6.36 发布公告

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

在实践中，屏障因扼杀块 I/O 性能而臭名昭著，以至于管理员经常想要关闭它们并承担风险。虽然当代硬件提供的标记队列操作应该可以很好地实现障碍，但尝试利用这些功能通常会遇到困难。因此，在现实世界中，屏障是通过在发出屏障操作之前简单地排空 I/O 请求队列来实现的，并抛出一些刷新操作以使硬件实际将数据提交到持久媒体。Queue-drain 操作会导致设备停止运行，并杀死充分发挥性能所需的并行性；使用障碍物会很痛苦也就不足为奇了。

还有这篇关于公平 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