@naota344の今週のLKML

今週は

  • [PATCH v3] xen block backend.
  • [RFC] [PATCH] drop_pagecache syscall

[PATCH v3] xen block backend.

http://permalink.gmane.org/gmane.linux.kernel/1129246
これは Xen のゲストにrawドライブをエクスポートするものです。LVMや iSCSIなどでも使えます。カーネル空間で動くので基本的に速いです。

http://permalink.gmane.org/gmane.linux.kernel/1132295
ベンチマークの結果がこのメールでしめされています。

http://permalink.gmane.org/gmane.comp.emulators.xen.devel/103184
このメールの簡単なサマリによると

xen-blkback (kernel) のバックエンドは qemu の qdisk (usermode)のバックエンドよりかなりパフォーマンスがいい。また、CPU使用率も kernel ベースのバックエンドの方がよい。

と、いうことです。まぁカーネルユーザランドを比べればそうなるのはあたりまえですがね…。

[RFC] [PATCH] drop_pagecache syscall

http://permalink.gmane.org/gmane.linux.kernel/1131637

特定のファイルシステムのページキャッシュを削除するシステムコールを導入しよう、というRFC。使用例としては、ファイルシステムベンチマークをとるソフトあたりでしょうか。

Linuxではページキャッシュを削除する方法はいまのところ以下の2つがあります。

/proc/sys/vm/drop_caches に 1 を書きこむことでページキャッシュが削除され、2を書きこむことで dentryと inodeとが解放され、3でその両方が解放されます。この方法はシステム全体のページキャッシュ・dentry・inodeに対して行なわれるので、特定のファイルシステムのキャッシュだけを削除したい、という用途には使うことができません。

posix_fadvise は (int fd, off_t offset, off_t len, int advice) といような引数をとって呼ばれる関数です。だいたい引数の意味はわかりますね。あるファイル(の指定した範囲)にアクセスするパターンを advice の値で指定することができます。 advice には以下のものが指定されます。

POSIX_FADV_NORMAL 通常の読み書き。デフォルトのパターン
POSIX_FADV_SEQUENTIAL 前から順番にアクセスする
POSIX_FADV_RANDOM ランダムな順番でアクセスする
POSIX_FADV_NOREUSE 指定した範囲は一度しかアクセスされない
POSIX_FADV_WILLNEED 指定した範囲を近いうちにアクセスする
POSIX_FADV_DONTNEED 指定した範囲はしばらくはアクセスしない

こういった advice によって、実際になにが行なわれるかは実装依存になります。 Linuxの場合だと

POSIX_FADV_NORMAL 先読み(readahead)がデフォルトのサイズになる
POSIX_FADV_SEQUENTIAL 先読み(readahead)がデフォルトの2倍のサイズになる
POSIX_FADV_RANDOM readaheadが無効になる
POSIX_FADV_NOREUSE なにもしない
POSIX_FADV_WILLNEED 指定した範囲をページキャッシュにいれようとする
POSIX_FADV_DONTNEED 指定した範囲をページキャッシュから削除する

と、いうことでファイルシステムをざっとparseして、全てのfile descriptorに対して posix_fadvise()を行なえば特定のファイルシステムのページキャッシュを削除できるのですが、これはあまりスケールしません。

ということでこの新しいシステムコールRFCが出されています。

http://permalink.gmane.org/gmane.linux.kernel.api/2323

その後 posix_fadvice() に POSIX_FADV_DONTNEED_FS とかいう新しいadviceをつけくわえるほうが簡単じゃないか?という意見が出され

http://permalink.gmane.org/gmane.linux.kernel.api/2334
それを受けて posix_fadvice() 版のRFCも出されています。細かい仕様まわりでつっこみが入ってますが基本的な機能自体への反対はないようなのでやがてマージされるのではないでしょうか。