 |
|
|
| 前のページ 1 2 3 4 次のページ
|
|
| CPUビジー型の考察
|
アドレス0xc0160de8の命令が最も頻度が高い結果となった。ソースコードとの突き合わせを行った結果、この処理はdo_generic_file_write()の中で呼ばれている__copy_from_user()であり、__copy_user_zeroing()にマクロ展開される。
|
ssize_t
do_generic_file_write(struct file *file,const char *buf,size_t count, loff_t *ppos)
{
（中略）
status = mapping->a_ops->prepare_write(file, page, offset, offset+bytes);
if (status)
goto sync_failure;
page_fault = __copy_from_user(kaddr+offset, buf, bytes); ←ここ
flush_dcache_page(page);
status = mapping->a_ops->commit_write(file, page, offset, offset+bytes);
（中略）
}
|
|
#define __copy_user_zeroing(to,from,size) |
|
\ |
do { |
|
\ |
int __d0, __d1; |
|
\ |
__asm__ __volatile__( |
|
\ |
"0: rep; movsl\n" |
←ここ |
\ |
" movl %3,%0\n" |
|
|
"1: rep; movsb\n" |
|
\ |
（後略） |
|
|
|
__copy_from_user()は、ファイルに書き込もうとしているユーザ空間のデータをカーネル空間のページキャッシュに書き込む（コピーする）処理である。
このコピーはI/Oの書き込み処理の中でも最も中心といえる処理であり、これがプロファイリングのトップにあるということは書き込み処理に効率よくCPUが費やされていることを表している。厳密な意味では、この__copy_from_user()が呼ばれる回数自体に無駄がないかどうかなど、さらなる追及の余地があるが今回の評価ではそこまでは及ばなかった。
OProfileの実行結果より、CPUビジー型の場合は容易に実行ボトルネックを発見できることがわかる。
|
| CPUアイドル型（I/Oビジー型）
|
CPUアイドル型については、パターンID 1を取り上げる。
プロファイリング結果より、CPUはhlt命令による休止状態にあることが多かった。これは、I/Oリクエストが処理されるスピードよりも、CPUを使ったデータコピー処理のスピードのほうが速かったため、I/Oリクエストが累積してCPU側が待たされていた状態にあったと考えられる（I/Oがビジーであると言える）。
そこで、実際にどれだけのI/Oリクエストの蓄積があったのかをLKSTによって調査した。マスクセットとしてbufferとblkqueueを使用して測定し、CPUアイドル型（I/Oビジー型）パターンとCPUビジー型パターンとの比較を行った。
頻度を回数から割合に変換してグラフ化すると図3のようになる。CPUアイドル（I/Oビジー）であるパターン1はCPUビジーであるパターン9に比べて所要時間のオーダが1近く長いことがわかる。それだけI/Oリクエストの処理が相対的に遅かったことが見てとれる。
図3：I/Oリクエスト到着からI/O完了までの時間（buffer）
次に、I/O要求が来た時のリクエストキューの長さ（blkqueue）についても比較する。平均値についてグラフ化すると図4のようになる。
パターン1（CPUアイドル型）はディスクが1台のI/O、パターン9（CPUビジー型）はディスクが4台のI/Oである。パターン1の平均値が非常に高く、常にI/Oリクエストがほぼ上限（512）近くまで溜まっていたことが見てとれる。これはデバイスドライバのルーチンによるI/Oリクエストの処理が飽和状態にあったことを表しており、一般的にデバイス側の処理限界に突き当たっていることが多い。
図4：I/O要求が来た時のリクエストキューの長さ（blkqueue）
この比較は、ディスクコントローラの条件が同一で、ディスクドライブの数が異なるケース同士の比較であるため、ディスクドライブの転送速度の上限に達していると推定される。このように、OProfileとLKSTを組み合わせることによってI/Oの挙動の差を明確化することが可能となる。
|
| ロック競合型
|
誌面の関係で詳細は省略するが、LKSTを利用することによって、ロックを待つ場所（busywait）とロックの時間（spinlock）を測定することができた。その分析結果より性能上問題となるグローバルなカーネルロックを発見した。
グローバルなカーネルロックは、これまでにカーネルの改良によってその数を減らしてきたが、MIRACLE LINUX V3.0にもまだある程度残っている。カーネル2.6.10と比較すると、さらにいくつかのグローバルロックが削除されている。これらについてMIRACLE LINUXでも削除を検討することが可能と考えられるため、今後の課題のひとつとしたい。
|
| 関数 |
MIRACLE LINUX V3.0での位置 |
2.6.10カーネルでの状態 |
| sys_ioctl() |
fs/ioctl.c |
残留 |
| sync_old_buffers() |
fs/buffer.c |
sync_old_buffers()がない |
| permission() |
fs/namei.c |
削除 |
| schedule() |
kernel/sched.c |
残留 |
| ext3_delete_inode() |
fs/ext3/inode.c |
削除 |
表7：グローバルなカーネルロック
|
前のページ 1 2 3 4 次のページ
|
|
|
|
|
著者プロフィール
ミラクル・リナックス株式会社 吉岡 弘隆
2000年6月ミラクル・リナックス(株)設立、それ以前は日本オラクルにてOracleデータベースのサポートを担当していた。オープンソースとの出会いは、1998年米国Oracle出向時にNetscapeのソースコード公開がきっかけ。
ミラクル・リナックス株式会社 取締役
日本OSS推進フォーラム ステアリングコミッティ委員
OSDL Japan アドバイザリボードメンバー
|
|
|
|
|
|
