優雅な生活の設計と実装

The Design and Implementation of the Gracious Days


LAST MODIFIED: 2004/08/09 14:47:12 UTC

新しい秩序の確立は、他の何にも増して難しく、
成功する可能性が低く、危険な事業である。
改革者は旧秩序から利益を得ている
全ての者を敵にまわし、
新秩序から利益を受けるはずの者からは
及び腰の支持しか集められない。
--- Niccolo Machiavelli, The Prince

この種の「保護」は初心者を保護するかも知れないが、
熟練ユーザを窮地に追い込むことになる。
というのは、何が親切であり、何が適切でないかかという
オペレーティングシステムの考え方の裏をかくことばかりに
かなりの労力を費やさなければならないからである。
--- A.S.Tannenbaum, Modern Operating Systems


不定期更新の日記です。ディスクスペースの関係上、 あまりに古くなったものは順次消していきます。 この日記の更新は、今野さんの *BSD Diary Links から取得することが可能です。

August 2004

感想はこちらまで (内容は匿名のメールで送られます)

コメント:

注: お返事が必要な場合は直接メールください。 ただし、確実にお返事するかどうかはわかりませんのであしからず。

Monday, August 9

* allbsd.org down on Aug 10 and 11

お知らせ: 電源の法定点検のため、allbsd.org 全体が 08/10 の朝から 08/11 の夕方にかけて停止します。 www, ftp, cvsup, cvsync, rsync, cvsweb の各サービスもすべて停止しますので、ご注意ください。

Sunday, August 8

* DragonFly

DragonFly 1.0 がリリースされて 1 月近く経っているのだけど、 今まで追っかけてみた印象を書いてみる。

ずーっと感じてるのは、安定性とか QA に対する意識が薄いということ。 日本語で書かれたニュース記事では「FreeBSD 4.x 系列の安定性」とか 「スレッドを使っていて効率がいい」とか書いているものがあるけど、 本当に使ったり、調べた上で書いているのか、とても怪しい。 少なくとも 1.0 の時点では messaging, new vfs, lwkt ともに実装が不完全で、 特にユーザランドユーティリティはぼろぼろです。 sockstat(1) が正しく動かなかったり、per CPU で持つようになったテーブル (たとえば net.inet.tcp.stats とか net.inet.tcp.pcblist) を 操作するものは、SMP マシンで変になったりします。

開発の意志決定は当然ながら dillon がやっているのですが、 開発体制や成果物の印象は、NetBSD に近いのでは、と思います。 動作がおかしかったら、自分でちょこちょこと修正してしまえる人にはおすすめです (そういう人は、どれでもいいような気もしますけど)。 ただし、単に使うだけの人は、手を出さないほうがいいかも知れません。 あれができない、これができないとストレスばかりが溜ることでしょう。 少なくとも、kernel@dragonflybsd.orgcommits@dragonflybsd.org を読まずに使うのは無謀かと。

FreeBSD 4.x や 5.x を使っていた人なら、 違和感はほとんどないと思います。ports は FreeBSD のものを使いますが、 いくつかはそのまま使えないため、/usr/dfports というツリーが用意されています。 dfports は port overrides と呼ばれるもので、FreeBSD の ports のうち、 DFly で動かないものだけが収録されてます。 まずは /usr/dfports を調べて、無ければ FreeBSD の ports を使いましょう。 それでも動かないものは、自分で修正するなりする必要がありますけど。

‥‥と、魅力のなさばかり強調するのも何なので、 1.0-RELEASE でも使える特徴的な機能をひとつ。 プロセスをサスペンド状態にして、あとで再開できるという checkpoint/restart という機能があります。 具体的には現在の状態をチェックポイントファイルというファイルに書き出して、 checkpt(1) を使って復活させることができる、というものです。

カーネルの対応部分は ckpt_checkpoint() というシステムコールで、 checkpt.ko というカーネルモジュールになっています。 SIGCKPT (33 番) が追加されており、Ctrl-E を押すと、 その時点のチェックポイントファイルが簡単に生成可能です。 関連 sysctl は kern.ckptgroupkern.ckptfile です。 イメージとしては coredump に近いかも知れません。内部の実装も、 elf_coredump() を使ったりしてます。

ソケットやデバイスファイルを開いている プロセスは、checkpt(1) を実行してもきちんと復活しないのですが、 通常ファイルについては問題なく復活できます。 セキュリティ的にはいろいろ問題があるのですが、一度お試しあれ。

DFly が目指しているのは理解しやすいスケーラブルなカーネルです。 FreeBSD 5 のような reentrant mutex モデルを採用すると、正しくロックされているかどうか、 という点に神経を使う必要があって、たとえばそのサブシステムを改良しようと思った時に、 どこをどういう順番でロックする必要があるのか、熟知していなければならなくなります。 dillon が、ことあるたびに指摘していたのは、この mutex の把握が難しい、ということです。 現に、FreeBSD 5 ではロックが正しいかどうか検証するために、 witness などの検証用ルーチンを追加しています。確かにプログラム的に検出させるのは 便利ですが、コードを書く側がそれなしでは間違いを把握できないというのは、 まあ健全とは言えません。

ざっくりと FreeBSD の SMP 実装を振りかえると、次のようになります。

FreeBSD の SMP は、3.x で Big Giant Lock (BGL) モデルを使っていました。 BGL モデルは「カーネルが 2 個の CPU で同時に実行されないようにする」というものです。 片方がカーネルに入っている間に、他の CPU をカーネルに入れないようにすることで、 同時に同じ資源にアクセスすることを防ぐというわけです。 この方法は実装が簡単ですが、2 個以上のプロセッサでは効率が非常に悪くなります。

そこで 5.x の段階で BSD/OS 5.0 のコードを参考に、 reentrant mutex モデルという方式を採用することにしました。 これは複数の CPU が同時にカーネルに入れますが、 同時にアクセスされると困る資源に mutex (mutual exclusion object) というものを用意します。カーネルが資源を使う時に、この mutex を「かけ」ます。 mutex がかかっている資源を他の CPU が使おうとする場合には、 その mutex が解除されるまで実行を待つか、 他の資源を割り当てることができるなら、他の資源を割り当てます。 カーネルが再入可能になり、BGL を使うよりもロックを待つ可能性が低くなるので、 効率が良いと言われているわけです。grog@ は「32 個以上のプロセッサでも効率的に動くだろう」とか言ってます。

5.0-RELEASE が遅れに遅れたのは、 この reentrant mutex モデルへの書き換えが難航したのが一因になっています。 どの資源を mutex で保護すべきか、どういう順序でそうすればいいのか、 というのを把握するのは、そのサブシステムを深く理解している必要があり、 さらにすべてのサブシステムを調査して書き換えなければなりません。 5.2.1-RELEASE でも、BGL はまだ残っています。ちなみに起動メッセージに出てくる [MPSAFE], [GIANT-LOCKED], [FAST] という表示は、そのデバイスに BGL が残っているかどうかを示してます。

DFly は各サブシステムを messaging を使うように抽象化して、 SSI (single system image; 複数のシステムが、 全体としてひとつに見えるようにする技術のこと) が実現できるような構成を目標としています。 性能的に mutex model がいいのか、dillon の lwkt model がいいのかは、実装ができあがってから比較してみないと何とも言えないと思いますが、 DFly では、複数のカーネル処理をシリアライズするための機構を用意して、 各サブシステムはロックについて神経質になる必要がなくなっています。 きちんと実装できれば、確かに開発する側は楽になるでしょう。

そういうわけで、FreeBSD 4.x をベースにしてますけど、 文書も十分ではありませんし、安定してるわけでもありません。 他の *BSD と比べてもゴールが独特で、追っかけていて面白いのですが、 今の FreeBSD のように、 アプリケーションプラットフォームとして何らかの目的で運用できるような水準に達するには、 まだまだ時間がかかるでしょう。