読者です 読者をやめる 読者になる 読者になる

テストステ論

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

(writeboost report) writeboostとbcacheのランダムライト性能比較実験

どうやら, device-mapperのメンテナが気になっているのは, writeboostがランダムライトに特化したと言っても, bcacheだってこの点はかなりうまくやるはずだから, ちゃんとした比較結果がないとマージの判断が出来ないなということのようである.

非常にめんどくさいが, 以下の要領でざっとした計測を行う.
bcacheはiodepthが低い時に性能が出ないようである(http://bcache.evilpiepirate.org/), まずはこの点で差をつける. writeboostはiodepthあまり関係ないはずである.
あと, キャッシュの検索がCPUを食うのではないかと予想する. この点, writeboostは軽く作ってある. writeboostを使ってみたらCPU食いまくってどうしようもありませんということでは話にならないからだ. そもそも, キャッシュが必要となるようなストレージでは, CPUが貧弱な場合に, CPUネックに追い込まれる可能性がある. この点からも, 無駄なCPU処理は避けなければいけない. writeboostがライトというリードより重いパスに専念して軽さに最適化したというのはこの意味もあるのだ*1.
ざっと見た限り, closureという構造の定義と乱用も, CPUをかなり使うのではないかと思う. これはスケジューリングが必要ではないですか. たぶんだが, 何かの実行を木構造で持って(parentとかいうメンバがあるし), あとは他の実行がwaitするのを待つための仕組みだろう. I/Oを順序づけるために利用しているのだと思う. 美しい仕組みだとは思うが, カーネルの世界ではやりすぎだと思う. Kentは関数野郎なのだろうか.

struct closure {
        union {
                struct {
                        struct workqueue_struct *wq;
                        struct task_struct      *task;
                        struct llist_node       list;
                        closure_fn              *fn;
                };
                struct work_struct      work;
        };

        struct closure          *parent;

        atomic_t                remaining;

        enum closure_type       type;

#ifdef CONFIG_BCACHE_CLOSURES_DEBUG
#define CLOSURE_MAGIC_DEAD      0xc054dead
#define CLOSURE_MAGIC_ALIVE     0xc054a11e

        unsigned                magic;
        struct list_head        all;
        unsigned long           ip;
        unsigned long           waiting_on;
#endif
};

struct closure_with_waitlist {
        struct closure          cl;
        struct closure_waitlist wait;
};

基本的にはこの2点と, あとは解析のためにblktraceをとり, bcacheのキャッシュへの書き出し方法を探る. ドキュメントによると, bcacheはメタデータとデータというものを別に扱っているようである. メタデータの更新に永続処理を使いすぎていないかとか, ここらへんが気になる.

最高性能を示す意味で, キャッシュをramdiskとした時の性能も測っておきたい.

あまり手間をかけたくないので, ざっくりと プロセス数(1, 4) x iodepth(4, 32)の計4通りで測る. たった4通りなので一瞬で終わりそうだが, 結局その周辺も色々測ることになるし解析のための時間もかかるので, これだけでもとても大変と思う.

とりあえず計画の共有まで.

*1:さらに, SSDでライトを受け止めてあげることによってbackingのRAIDのCPUネックも避けることが出来る. RAIDカードはすぐにCPUネックになってしまうのだ