テストステ論

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

(dm-lc report) barrierをmigrationに持っていく方式の検討

http://akiradeveloper.hatenadiary.com/entry/2013/07/28/224016

において, segment_headerにpersistentフラグを持たせて, barrierがあったかどうかを覚えておき, フラグが立っている場合だけflushするという実装は, 破綻することを明らかにしました. キャッシュデバイスから返したACKを反故にしてしまうことが原因でした.

まともに動きそうな実装は, 以下. この話題は単なる性能最適化に関するものであり, 複数segmentのmigrationを非同期化するbatched migrationが実装された今, その数を大きくすることによって補填出来てしまうような機能なので, 意味ないかも知れないが, 一応検討する.

flush_proc()の中でbarrier bioのリストを見て,

  • REQ_FUAがついていれば, fuaフラグを立てる.
  • REQ_FLUSHがあれば, last_barrier_flushed_idを, このセグメントのidにセットする.

migrate_proc()の中で,

  • fuaフラグが立っていれば, fuaでmigrateする.
  • segmentのidが, last_barrier_flushed_id以下であれば, flushする. (#)

この方式の効果はワークロードに依存する. 例えば, 定期的にREQ_FLUSHが発行されてしまう場合ではほぼ無意味である. なぜならば, 上記(#)がほぼ常に成り立ってしまうからである. 逆に, REQ_FLUSHがほとんどない場合であれば効率化になりうる. だが, そんなワークロードあるだろうか?現実的にはあまりないように思う.

以上より, バグる危険性を冒してまで実装する意味はないと思うが, 実装としてはほとんどオーバーヘッドがないので, 正しくクリーンに実装出来るならば, 実装すれば良いと思う. 「どうすれば良いのか分からない時はフラッシュする」というデフォルト実装があり得るので, この性質を利用してきれいに実装することも可能だろう. この最適化が効くケースを, 私自身が見逃しているだけかも知れないので, この最適化が完全に無駄だとは言い切れない. やってみると以外に効果がありました/なかったですは良くある話なので, スタート地点が「効果ないでしょう」な分だけ, 心的コストは低い. もっとも, 効果の測定方法が難しいんだけど.