テストステ論

高テス協会会長が, テストステロンに関する情報をお届けします.

(writeboost report) ライトバック時のソーティング

ミクラスは今, dm-cryptの高性能化に取り組んでいる. dm-cryptはCPUネックを解消するためにbioごとにworkを作って, wqで処理をする. しかしそれ自体に, I/Oがあまりに多い時にメモリ不足に死ぬみたいな問題があるだけでなく, 他にも色々と問題があるらしい. 以下のパッチは, その対策をしたら生まれた問題を解決するために, bioをRBツリーでソートしてからI/Oスケジューラに送るというものだ.

http://www.redhat.com/archives/dm-devel/2014-March/msg00163.html

まず直感的に, この仕組みは一般化出来る. そして, その一般的な仕組みはライトブーストに適用出来る. ライトブーストのライトバック(SSD->HDD)は, 一つ127個の4KBデータが入ったセグメントという単位を複数個(設定可能)ライトバックする. 例えばこれが10個の場合は, 1270個の4KBライトが一気にライトバックされる. これらは概念的にランダムライトになってしまう(もともと上から来たライトと同じ)が, たくさんのセグメントを一気にライトバックすることで, 時間的に離れたものが空間的に近い場合, マージする可能性がある. 例えば, 1番目のデータと1270番目のデータが実は隣接していたという奇跡も起きる. そうでなくとも, I/Oスケジューラに判断の猶予があることには利がある. すなわち, ライトブーストを入れるだけで, HDDへのライトを効率化することが可能となる(現実的には, バリアをSSD上で吸収出来るなど, 他にも利点がある).

しかし, このスレッドでも言うように, ソーティングはI/Oスケジューラが行うものだ. ミクラスは「これを信用しない」と言っている. そしてこのスレッドに対しては当然のごとく, 「いや, nr_requestsをデフォルト以上にすればいいじゃん?」がついている. しかし無視してマージしていい. 私はこの機能を好ましく思う.

ライトブーストのライトバックは, 非常に特殊と言ってよい. 複数セグメントのライトバックを全部並び替えて, 最適化な順序にしてからライトバックすることが許されてしまうからだ. これは, dm-cryptのケースよりソーティングの貢献が大きい. ただし, まともに調べていないものの, 私はライトブーストの件でいえば, I/Oスケジューラが多くはマージしてしまってると考えている. だが, 戦略的なことを考えると, これは実装していい. なぜか?

  1. メンテナが良いと思ってるものを実装する方が, その実装の正当性を主張しやすい(上司が良いって言ってるんだから良い理論)
  2. 一般化して切り出せば, dm-cryptと実装を共有出来る可能性がある. そうなると, その共通部分と一緒にライトブーストもマージがあり得る(抱き合わせ理論)
  3. I/Oスケジューラの挙動によらず, 最適な順序でライトバック出来ることは, ライトブーストのライトバックを利用することの有効性の主張を確実にする(合格率80%ではなく100%だと生徒倍増理論)

以上の理由により, 私は, ライトブーストのライトバックをソーティングするコードを追加しようと思う. その際にはなるべく一般化すること. 一般的な名前をつけて, factoring outが明らかに可能であることを主張すること. 名前は, sort_writesとか, 明らかにソートする感を出すべきだ. この機能のenable/disableもつけるべきだろう.

この最適化は特に驚くことではない. 私も, 当然, ソーティングをする意味はあるかも知れないと思っていたし, たくさんのライトを同時に発行出来る権利があるのだからこれを利用した最適化があってよいだろうとは思っていた(I/Oスケジューラにとっては, これらのまとまりが見えない. 最適化は上位でやる方が情報が多く, 良い場合もある. ブロックでやってるようなことをファイルレベルでやるような技術は山ほどあるし, 今回のは, ドライバーレベルスケジューリングとでも呼べる). 今回はそれがソーティングたまたま決まっただけだ. 他にやり方があるかも知れないが, 上司が良いって言ってるんだからその通りやるのがOSS社畜の仕事術だ.


(追記)

我々のボスであるマイクは, この仕組みを大変お気に入りのようである. 速攻で入れないとね

http://www.redhat.com/archives/dm-devel/2014-March/msg00166.html