メモリが少ないときのI/Oでパフォーマンスが大幅に落ちたりOOMが出る問題は2.6.36で解決

実は仕事でこの問題に遭遇し、ある程度詳細までわかっていたのだが、Linuxの人たちはサーバ使ってるから「そんなクソHW変えろ」とか言い出すんだろうなと思ったら、真面目に直してくれた模様。

1.7. Improve VM-related desktop responsiveness
There are some cases where a desktop system could be really unresponsive while doing things such as writing to a very slow USB storage device and some memory pressure. This release includes a small patch that improves the VM heuristics to solve this problem.

2.6.36でちゃんと解決された模様

http://groups.google.co.jp/group/linux.kernel/browse_thread/thread/ab5301f243330ffe

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=e31f3698cd3499e676f6b0ea12e3528f569c4fa3


結局の頃、スレッドというかタスクの優先順位がついていないのが問題。

・Linuxの場合、通常の書き込みは全部非同期書き込みになっていてメモリに蓄えられる。同期書き込みですら、非同期書き込み＋終了待ちになっている。
・非同期書き込みで確保されたメモリは定期的にディスクにフラッシュされる（vm_cache_pressureとかdirty_なんとか_thresouldとかそこらへん）
・新しい書き込みを開始するときにメモリが無いと他の書き込みを待つ。congestion_waitがキーワード。
・メモリが少なかったり、ディスクの速度が遅いと書き込み前に空きメモリが枯渇する。このとき、ディスクへの書き込みを早く終わらせないと次にいかないのに、空きメモリが枯渇している場合は他のを待つという行動に出るため、待たせているのが自分なのに他のタスクに実行権を渡してしまう。
・さらに2.6.32ぐらいまでの、嘘フラッシュは、あるタスクが1秒以内に終わらない場合、パフォーマンスが足りないと判断して新たに書き込みスレッドを増やそうとする。メモリが足りないから遅いのに、スレッドを増やして解決しようとするのでOOMが発生する。これは2.6.34ぐらいで、ブロックデバイスごとのスレッドを作成することで解決してある。

とまあ、パフォーマンスの根幹部分にもかかわらず、結構適当。大体これぐらいのテストもしてない設計者ってどうなの？と言いたいところだが、タダだからな。これでメモリが少なくディスクも遅い組み込み用途でのパフォーマンスも改善しやすくなったのではないかと予想している。