每当磁盘 I/O 较高时，系统往往会比平时慢得多且响应速度慢。 Linux内核在这方面的进展如何？这个问题是否正在积极解决？
答案1
我认为大部分已经解决了。我在 2.6.36 中在重 IO 下的性能有所提高，我预计它在 2.6.37 中会提高更多。看这些 佛罗尼克斯文章。
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 内核中也发现了这一点。
它似乎区块障碍正在消失这也应该有助于提高性能。
在实践中，屏障因破坏块 I/O 性能而臭名昭著，以至于管理员经常试图关闭它们并承担风险。虽然当代硬件提供的标记队列操作应该相当好地实现屏障，但利用这些功能的尝试通常会遇到困难。因此，在现实世界中，屏障是通过在发出屏障操作之前简单地清空 I/O 请求队列来实现的，并抛出一些刷新操作以使硬件实际将数据提交到持久介质。队列耗尽操作将使设备停顿并终止充分性能所需的并行性；毫不奇怪，使用障碍可能会很痛苦。
我想说，IO 的重新唤醒是在 2.6.28 发布 ext4 的时候发生的一件大事。以下链接是Linux 内核新手内核版本中，您应该查看“块”和“文件系统”部分。这当然可能是不公平的情绪，或者就在我开始观看 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