2008年4月27日日曜日

王子駅が

玉子駅に見えて困る

2008年4月22日火曜日

墓でかい

現代版古墳群的

2008年4月12日土曜日

texinfo で日本語処理

Google で検索すると jtexinfo.tex を利用しないと動作しない、という記事ばかり引っかかるが、手元の環境では
TEX=ptex texi2dvi file.texi
とするだけで動作した。

2008年4月3日木曜日

路上にカツラ

南青山付近にて

Linux 2.6.25

そろそろリリースが迫ってきたようなので、目立った新機能をいくつかまとめてみる。引用は kernelnewbies.org より。

  • RCU プリエンプションサポート
    RCU は、Linux で用いられる非常に強力なロック方式であり、単一システム上において非常に多数の CPU にまで適応できる。しかしながら、 Linux を RT OS 化すべく開発されているリアルタイムパッチセットとはうまく適合しない。それは、その一部がプリエンプション不可能であるため、 RT 負荷に対して過大なレイテンシを発生させるからである。2.6.25 では、 RCU もプリエンプション可能となり、レイテンシの原因は削減される。 Linux は、より一歩 RT らしくなる。
    確かにありがたい気がするけど、一体どうやって実現されているのか。

    ポイントは、今のデータ群を触っているスレッドの数 (A とする)と、昔のデータ群を触っているスレッドの数 (B とする)をいつも数えておくことである。 rcu_read_lock で、 A をインクリメントする。rcu_read_unlock で、 A と B のうち、自分がインクリメントしたほうをデクリメントする。

    B は単調減少のはずで、ゼロになれば、昔のデータ群を解放し、 A と B をスイッチする。これを繰り返す。

    大まかな設計はこんな感じで、どちらかというと単純だが、これをいかに一切スピンロックとかメモリバリアを使わずにやるか、という細かい実装の話が複雑で、むしろそこに力が入っている。いかにも Linux らしい。(A と B をスイッチしたよ、という情報が各CPUに伝わるのに時間がかかるのを考慮しないといけなかったり、 A や B を CPU ごとに管理しないといけなかったり、とかいった話である。)

  • FIFO チケットスピンロック
    特定の負荷において、スピンロックが不公平になる場合がある。例えば、スピンロックでスピンしているプロセスが、1,000,000回程度までスタベーションすることがある。通常スピンロックにおけるスタベーションは問題にはならない。というのは、スタベーションに気づけるような状態になるよりも先に性能問題が発生するからである。しかしながら、テストで示されているのはその逆で、ロックに対して激しいコンテンションが発生して、プロセッサはロックを闇雲に取る、という、目立たないケースは、常に存在する。新しいスピンロックでは、プロセスは FIFO 順でスピンロックを取るようになる。

    255 以上のCPUで実行するように設定されたスピンロックは 32 ビット値を、それ以下のCPUの場合は 16 ビットの値を使用するようになった。おまけとして、 Linux がサポートできる CPU の数の理論的上限値は、 65536 プロセッサにまで引き上げられた。
    スピンロックとか、 RCU とか、いい加減もう枯れてそうだが、まだ改良すべきことはあるようだ。

  • プロセスメモリ使用量測定の改善
    プロセスがどれだけメモリを使っているかを測定するのは、案外難しい。特にプロセス群が使用メモリを共有している場合はそうである。 /proc/$PID/smaps (2.6.14 で追加) のような機能は役に立つが、十分ではなかった。 2.6.25 では、この測定を簡単にする新しい統計値が追加される。プロセスごとに /proc/$PID/pagemaps ファイルが新たに作られ、カーネルはこのファイルの中に、プロセスが使っている各ページに対応する物理ページ配置を(バイナリ形式で)エクスポートする。このファイルを他のプロセスの同じファイルと比べることで、共有しているページがわかる。別のファイル /proc/kpagemaps では、システムのページに関してまた別の種類の統計値を公開している。パッチの作者 Matt Mackall は、 2 つの新しい統計値、 "プロポーショナルセットサイズ (PSS) - 共有ページを共有しているプロセスの数で割ったもの" と、 "ユニークセットサイズ (PSS) - 共有されていないページを数えたもの" を提案している。最初の統計値、 PSS は、 /proc/$PID/smap の中の各ファイルに追加される。この HG リポジトリの中に、これら統計値全てを使うコマンドライン及び GUI ツールのサンプルがある。
    あまりメモリまわりは知らないのだが、 2.6.24 までなかったのが疑問な機能ではないだろうか。このあたりの指標は、実は Windows のほうがいいんだろうな。

  • メモリ資源コントローラ
    メモリ資源コントローラは cgroups ベースの機能である。 cgroups, 別名 "Control Groups" は、 2.6.24 でマージされた機能であり、いくつかの "資源コントローラ" の土台となり、プロセススケジューリングやメモリ確保といった、システムの様々な資源を管理するための汎用的な枠組みとなることを目的としている。 cgroups は、仮想ファイルシステムに基づいた統一されたユーザインタフェースを持っている。管理者は、ファイルシステムから選択したタスクのグループに対して任意の資源制約を割り当てることができる。例えば、 2.6.24 では、 Cpusets と Group Schueduling の二つの資源コントローラがマージされた。前者により、任意に選んだタスクのグループ、すなわち cgroup に対して、 CPU 及び メモリのノードを設定することができるようになり、後者により、 cgroup に CPU の帯域ポリシを設定することができるようになっている。

    メモリ資源コントローラにより、タスクグループ -cgroup- に対するメモリの動作を、残りのシステムから分離することができる。

    • アプリケーションまたはアプリケーションのグループを分離する。メモリを食おうとするアプリケーションを分離し、小さいメモリ量に制限する。

    • 制限されたメモリ量の cgroup を作成する。これにより、 mem=XXXX で起動する方法の代わりとなる良い方法である。
    • 仮想化ソリューションが、仮想マシンのインスタンスに割り当てたいメモリ量を制御できるようになる。

    • CD/DVD 書き込みソフトが、システムの残りによって使われるメモリ量を制御して、利用可能な メモリが不足することにより書き込みが失敗することがないことを保証できるようになる

    設定のインタフェースは、他の cgroups と同様、 "-o memory" オプション付きで cgroup ファイルシステムをマウントし、適当な名前のディレクトリ (cgroup) を作成し、 cgroup ディレクトリの中の 'task' ファイルに PID を書き込むことによりタスクを追加し、 'memory.limit_in_bytes' 、 'memory.usage_in_bytes' (cgroup 向けのメモリ統計値) 、 'memory.stats' (RSS 、キャッシュ、非アクティブ/アクティブページ) 、 'memory.failcnt' (cgroup が制限を越えた回数) 及び 'mem_control_type' に値を書き込む、というものである。 OOM 条件も cgroup ごとに処理される。 cgroup のタスクが制限を越えると、 OOM が呼ばれて、当該の cgroup に含まれている全てのタスクのうちから、一つのタスクを kill する。

    2.6.24 で登場して便利だな、と思っていた cgroup が早速グレードアップされたようだ。特に OOM のあたりは、うまく使えば非常に魅力的な機能である。さらに I/O とかに適用されていくか。

  • latencytop
    遅いサーバ、飛び飛びの音声、コマ落ちした動画 - だれもがレイテンシの症状を知っている。しかし、何がシステムの中で本当に起こっているのか、何がレイテンシの原因なのか、どうすれば直るのか…。これらは難しい質問であり、すぐに良い回答があるわけではない。 LatencyTop は、(カーネル、ユーザ空間両方の)ソフトウェア開発者向けの Linux ツールであり、どこでシステムのレイテンシが発生しているのか、どんな種類の操作・動作がレイテンシが発生する原因となっているのかを特定することを目的としている。これを特定すれば、開発者は、最悪のレイテンシ問題を避けるようにコードを変えることができるようになる。

    レイテンシには多くの種類や原因があるが、 LatencyTop は、音飛びとデスクトップの処理落ちを引き起こすような種類、特に、アプリケーションが走って、有用なコードを実行したいが、現在利用可能な資源がない(ゆえにカーネルがプロセスをブロックさせている)場合にフォーカスしている。これは、システムレベルでも、各プロセスレベルでも行うことができ、システムで何が起こっているのか、そして、どのプロセスが遅延させられ、また遅延を引き起こしているのかを見ることができる。

    latencytop.org に latencytop のユーザ空間のツールとスクリーンショットがある。
    カーネルのスケジューラで、タスクがどこでスリープしているかの統計を取るようである。実際使ってみないことにははっきり言えないが、X 環境とか、込み入った環境でもっさりの原因を解析するには良さげなツールである。タスク構造体に余分なフィールドが取られるので、ディストリビューション標準カーネルには入りにくいだろう。

追記: 個人的には rndis ドライバの Windows Mobile 6 対応も重要な改善点である。