Linuxカーネルのアトミック操作

Linuxカーネル内のアトミック操作には、atomic_readとか、atomic_incといった関数があります。この場合の、アトミックというのは、スレッドが複数あったときに、メモリから変数を読んで、増やして、書き込むまで同時に増やそうとしないということを言います。
typdef struct {volatile int counter;} atomic_t;
というタイプが宣言されていて、atomic_read(v)とすると、(v)->counterが読まれます。counterは、volatileですのでgccが最適化せずにちゃんとメモリ上の値を読んで来ます。
また、atomic_incは、

static inline void atomic_inc(atomic_t *v)
{
__asm__ __volatile__ (
LOCK "incl %0"
:"=m" (v->counter)
: "m" (v->counter));
}

のようになっていて、LOCKプレフィックスが付いているので、数を1増やすのがアトミックに出来るようになっています。
LOCKは、"lock; "に定義されています。
また、BUG_ON(condition)というマクロがあって、conditionが成立した時、エラーメッセージを出しpanicします。
これだけわかると、

static inline struct dentry *dget(struct dentry *dentry)
{
if (dentry) {
BUG_ON(!atomic_read(&dentry->d_count));
atomic_inc(&dentry->d_count);
}
return dentry;
}

は、dentry->d_countが0だったらエラーメッセージを出し、アトミックに参照カウントを増やしてそのままdentryを返す関数であることがわかります。
このくらいだったらわかるのですけどね。
Linuxのソースコードを読むって、EmacsだとM-x cdでディレクトリを変えて、M-x grep-findで片っ端から検索していくことになります。どこに何があるのかを知らないと始まらないのでしょうがないですけど。
ちなみに、コマンドラインでは、
find . |xargs grep hogehoge
というのを、よく使います。

Paravirtualization

ゲストOSを少しだけ変更して、仮想化を行うことをParavirtualizaton(疑似仮想化、準仮想化)と言います。Xenは、Intel VTやAMD-Vの助けが無いとき、この方法で仮想化を行っています。また、VMwareは、VMI(Virtual Machine Interface)というParavirtualizationの規格を作ろうとしています。VMwareのサイトに、その企画書のバージョン2.5が置いてあります。また、Linux 2.6.20にそのバックエンドのパッチが取り込まれているのを見つけました。
そんなパラバーチャリゼーションなのですが、Ingo MolnarさんによりQEMU+KVMで行うパッチが作られたようです。タスクスイッチの性能評価が行われているのですが、実機の1/2くらいの性能が出ているようです。
http://redhat.com/~mingo/kvm-paravirt-patches/
また、kvm-develで開発が進められているようです。

UNIX magazine 2007 Winter

UNIX magzineに仮想化について特集が組まれています。広範囲に渡りいろいろな技術が紹介されていてすごいなと思います。仮想化は、大型コンピュータの世界では古くから使われている枯れた技術なんですね。IBM、HP、サンといったところでは当たり前のことなのでしょう。企業向けのサーバでは、既にノウハウの蓄積があるんですね。
TSS(タイムシェアリングシステム)と呼ばれていたマルチタスクがPCの世界で当たり前になったのと同じ歴史を歩いているのでしょうか。でも、複数のOSを動かしたときのメリットがイマイチ分かりずらい気もしますね。そういうことを言い出すと、まだマルチタスクが一般的でない時代に、一人の人が動かすだけなのにマルチタスクなんてメリットが分からないと言っているのと同じになりそうですけれど。仮想化が意識されないようになって初めて普及したと言えるようになるのではないかと思います。Mac上のParallelsのCoherenceモードがその先陣を切っているような気もします。

Lions' Commentary on UNIX 読み終わって

UNIXって、シンプルなコードでかかれてあるんだなと思った。それなりには複雑だけど。
コードを完璧に理解してコメントがしてあるのを随所に感じて、すごいなって思った。コメントが無ければ理解できないと思う。
ハードウェアに関することはわからなかったけど、それ以外のところはなんか理解できた気がしてる。大雑把だけど、よかったと思う。
C言語は、古い形式だし問題もあると思うけどね。
Linuxもこんな感じに読めたらなあ。

Lions' Commentary on UNIX iノード

iノードって何かなと思っていたのですけど、ファイルの属性とかの情報が入るデバイスのブロック#1がスーパーブロックで、その次の#2から#(N-1)にiノードテーブルという名で保存してあるのだそうです。
それとは別に、ディレクトリファイルというファイル名とiノード番号を対応づけるファイルが存在しています。ユーザーがファイルを開けと命令すると、まず、iノード番号を見つけ出して、その次にiノードテーブルを見つけて操作を開始するのだそうです。
Linuxのext2ファイルシステムは、どんな風になっているのだろうと思った。

Lions' Commentary on UNIX プロセス管理

これから3回ほど、Lions本について書きます。
シェルが自分自身をコピーして新しいプロセスを生成するということが書いてあるのを時々見かけるけれど、なぜかということがやっとわかった気がした。
プロセスを表す構造体にエントリーが確保されていることがプロセスが存在していることの証明になっているということなんだ。だから、新しいエントリーを作るときにコピーするんですね。
ということは、カーネルのプロセスとは全く別の構造体で定義されたユーザープロセスを生成するOSというのも可能なのか。KISSの法則には反するけれど。
生成するたびに違う構造のプロセスを生成していたら、管理できなくなっちゃうよねとか思った。

新年

明けましておめでとうございます。
今年は、OpenGLの移植を春頃までにやりたいなと思います。それとやり残していることをいくつかやらないといけないです。また、Core 2 Duoを買ってKVMを少しいじってみたいですね。