高ディスクI / O中のシステムパフォーマンス/応答性の改善に関する進捗状況は？
ディスクI/Oが高い場合は常に、システムの速度が大幅に低下し、通常よりも応答が遅くなる傾向があります。これに関するLinuxカーネルの進歩は何ですか？この問題は積極的に取り組んでいますか？
ほとんどの場合、それは解決されたと思います。重いIOは2.6.36で改善され、2.6.37でさらに改善されると思います。 これらphoronix 記事を参照してください。 。
WuFengguangとKOSAKIMotohiroは今週、これらの応答性の問題のいくつかに対処すると信じているパッチを公開しました。このパッチでは、「システムがメモリ不足と大量のダーティ/ライトバックページの下で応答しなくなる」バグと呼ばれています。この問題をLKMLに報告し、カーネルのvmscanに対して適用された2つのパッチをテストしたユーザーの1人であるAndreas Mohrは、成功を報告しました。 Andreasの問題は、ソリッドステートドライブがUSB 1.1経由で接続されているときに、EXT4ファイルシステムを作成するときにシステムが完全に応答しなくなる（VTへの切り替えに20秒以上かかる）ことでした。彼のシステムでは、/ dev/zeroファイルから300Mを書き込むと、問題はさらに悪化しました。
bug への直接リンクは次のとおりです。
また、Phoronixから
幸い、この問題が修正されたことを確認しようとしている他のLinuxユーザーのテストとレポートから、公開された比較的小さなvmscanパッチの方が問題にうまく対処しているようです。システムが圧倒的な量のディスクアクティビティを維持している場合、ユーザーインターフェイス（この場合はGNOME）はまだ100％流動的ではありませんが、以前よりもはるかに優れており、Linux2.6.35カーネルで現在も検出されています。
Phoronix 2.6.36リリース発表 もあります
ブロックバリアがなくなります のようですが、これもパフォーマンスに役立つはずです。
実際には、バリアはブロックI/Oのパフォーマンスを低下させるという不愉快な評判があり、管理者はバリアをオフにしてリスクを冒したくなることがよくあります。最新のハードウェアによって提供されるタグ付きキュー操作は、バリアを適切に実装する必要がありますが、これらの機能を利用する試みは、一般的に困難に直面しています。したがって、現実の世界では、バリアは、バリア操作を発行する前にI/O要求キューをドレインするだけで実装され、ハードウェアにデータを永続メディアに実際にコミットさせるためにいくつかのフラッシュ操作がスローされます。キュードレイン操作はデバイスをストールさせ、完全なパフォーマンスに必要な並列処理を停止します。バリアの使用が苦痛になる可能性があることは驚くべきことではありません。
これもあります 公正なI/Oスケジューリングに関するLWNの記事
IO 2.6.28でのext4のリリースの頃に大したこととして目覚めました。次のリンクは Linuxカーネル初心者 カーネルリリースです、あなたブロックとファイルシステムのセクションを確認する必要があります。これはもちろん不公平な感情かもしれません。あるいは、私がFS開発を見始めたとき、それはずっと改善されていると確信していますが、私はそれを感じています。 ext4の問題のいくつかは、 'IOスタックをよく見るようになりました。あるいは、ext4がすべてのパフォーマンスの問題を解決することを期待していたのかもしれませんが、そうでなかったのかもしれません。彼らは他の場所で問題を探す必要があることに気づきました。
2.6.28 、 2.6.29 、 2.6. 、 2.6.31 、 2.6。 32 、 2.6. 、 2.6.34 、 2.6.35 、 2.6.36 、- 2.6.37