2012年振り返り

何だかんだしている間に年が明けてしまったけど、Plan 9日記の振り返りをしておこう。2012年に書いたエントリ数は19。年々数が減っているけど、ついにPlan 9ネタがなくなってしまったｗ　ほとんど読書メモかイベントログだね。その中で一番ブクマが多かったのが、「「エラー忘却型コンピューティング」なんて言い出したのは誰だ！」、「いいね」が一番多かったのが、「スパコンにまつわる雑談」だった。

今年がどんな年になるかわからないけど、本日記は今年もマイペースに、誰も目を付けないニッチで重箱の隅をつつくようなネタを追求していきたい。

システムソフトウェア研究の将来

本年最後のエントリはちょっと無理してシステムソフトウェア研究の将来に思いを馳せてみたい。（おぉ、まだ酒は入っていないｗ）

去る12月6〜7日にコンピュータシステムシンポジウム（ComSys）2012が開催された。加藤和彦（筑波大）教授による基調講演「仮想化とシステムソフトウェア研究」では、Multics、Unix、Mach、そして同教授が関わったDSR/Planet、遠隔RPC、BitVisorなどの研究を振り返り、システムソフトウェア研究が目指した理想と社会が求めた現実とのギャップ分析が示され、非常に面白かった。イノベーションの源泉がシステムソフトウェアよりも上位層に移っているのは確かではあるが、システムソフトウェア研究者としては、例えばセキュリティなど、自分の研究と社会との関係をどう位置付けるかが重要と改めて感じた。また、質疑応答では、日本は特にインフラが見えにくいという問題があり、若い人にシステムソフトウェア研究への興味を喚起するにはその使命感をアピールすることが重要ではという指摘もあった。

情報処理学会のOS研究会などの動向を見ると、この分野が萎縮しているように感じることがある。しかし、海外に目を転じると、システムソフトウェア系の会議の参加者は年々増加しているそうである。Google、Microsoftを始めとする巨大インフラを持つIT企業の存在感が大きいし、研究の出口が見えている感がある。研究としての深みがないとか批判はあるだろうが、人は集まるし、高い質も保てているのではないだろうか。一方、日本でも、カーネル／VM探検隊やインフラエンジニアの勉強会は非常に盛んなところを見ると、まだまだ捨てたモノじゃないなと感じる。このような草の根というかボトムアップの活動と学会活動をうまく結びつけられないかなと、個人的には思っているのだが。。。

確かにシステムソフトウェアは地味だし、成果が出るまで時間がかかる。でも、コンピュータシステムが成立する上で必要不可欠なのある。まさに、「誇り高き3K」仕事。

分野が違えばこの手の縁の下の力持ち系の仕事の啓蒙活動は「プロジェクトX」や「メタルカラーの時代」など、いろいろなメディアでまとめられている。今ちょうど「メタルカラーの時代」を読んでいるのだが、モノを作る、社会的基盤を築く、社会や自然のシステム、メカニズムを探り創造する人々のインタビューが満載である。この本が出たのは1993年で、IT系の話題は磁気デバイス、通信衛星や海底ケーブルなどが中心で、しかもインターネットはもう存在するが、本書には「イ」の時も出てこない。ソフトウェアの話はTRONだけ。奇しくも坂村健先生は「TRONは21世紀のインフラ作り」と言っている。さて、90年代と比較しても、ソフトウェアの社会インフラとしての重要性は比べものにならないほど増大している。巨大土木事業と同じように、子供の世代にこのインフラは我々が作ったんだ、支えているんだと胸を張って言えるようになりたいではないか。

ComSysの懇親会で、プログラミング言語ではかなりいろいろな可能性にトライして失敗するという歴史を経てきたが、OSにはまだその可能性を探究し切れていないのではないかという話が出た。私ぐらいの歳になると、「OSとはかくあるべし」という固定概念で思考が固まってしまう。若い人にはその既成概念を打ち破って欲しいな（というのは無茶ぶり？）。来年はOS研究の最高峰、ACM SOSPの開催年である。「What is good systems research?」を読みながら傾向対策でもしてみたら？　まぁ、学会の傾向と対策からイノベーションは生まれないか。

「メタルカラー」の時代

はじめてのOSコードリーディング

Lions' Commentary on UNIX 読書会で親交のあった@superhogeさんが「はじめてのOSコードリーディング」を上梓される（「はじめてのOSコードリーディング」という本を出版します）。読書会の活動が書籍として結晶したことに感動するし、自分が生まれた頃のソースコードの解説本が今出版されるというのも感慨深い。

OSに限らず技術には理論と実践の両面がある。UNIX V6やLions本が出た頃は、OSの黎明期であり、その理論については論文などで知ることができたけど、実際にどのように作られているのか、その方法についての情報は手に入らなかった。そこにLions本が受け入れられた背景がある。翻って現在は、実践的な情報が氾濫している。で、どこから初めていいのかわからず思考停止に陥ってしまいがち。まず簡単なところ（しかし、トイOSではなく実用に耐える(た)OS）から一歩踏み出してみようというのが、本書の価値じゃないかな。

UNIX V6は約1万行とコンパクトにも関わらず、近代的なOSの基本的な概念はすべて実装されている。1万行というと、LinuxのDocuments以下よりも少ないｗ コンパクトな実装のOSならば探せばいろいろあると思うけど、その辺のトイOSとは異なり、UNIX V6は実用として使われた実績がある。バグがないとは言えないけど、短くてもよく考えられており、読む価値がある。あとロジックが単純という点も読みやすさに貢献している。ハードウェア資源に制限があるので、固定配列を線形探索が基本である。もちろんpre K&R CやPDP-11という問題点はある。pre K&Rには慣れるしかないのだが、PDP-11に関しては、ドキュメントが豊富だし、simhシミュレータで動かしながら動作を追うことができる。この際、プロセッサアーキテクチャも一緒に勉強してしまうのもよいかも。

少し自分語りをすれば、私においての「はじめてのOSコードリーディング」は、大学の研究室で開発していた独自OSだった。作っている人が隣にいるので分からないことは聞けたし、何しろそれを理解して改造できないと卒業できないので、必死だった。サイズも適当だったしね。論文は全く書けなかったけど、今の仕事の血肉になっているのは確かだ。

有名な1974年のCommunications of the ACM誌の論文（"The UNIX Time-Sharing System"）には、（あまり知られていないかもしれないけど）システムにソースコードを含めて出荷することの重要性が指摘されている。さらにシステム開発・保守の観点から、単にソースコードが見られるだけではなく、セルフ開発できるべきであり、そのために全ソースコードをシステム上に置く必要があると書かれている。とことんプログラマ向けの思考である。

閑話休題。この本をきっかけにOSの中の実装に興味を持ってくれる人が増えることを期待したい。一人で読むのは辛いという人は読書会などのイベント（はじめてのOSコードリーディング 読書会）を活用するとよい。

さぁ、正月休みにじっくり読むことにしよう。

はじめてのOSコードリーディング ~UNIX V6で学ぶカーネルのしくみ (Software Design plus)

スパコンとは何か

SC2012に向けての機内で金田先生の「スパコンとは何か」を読んだ。2009年の京、そして2011年のHPCIの事業仕分けに仕分け人として関わった東大情報基盤センタの金田先生によるスパコン解説本である。京はLLNLのSequoia (BG/Q)に抜かれてTOP500の2位になったが、今回のTOP500の目玉はORNLのTitan (Cray XK7)。TitanはOpteron + GPUというアーキテクチャで、ピーク性能は20PFLOPSと言われている。一般的にGPUの実効性能は高くないけど、NVIDIA Tesla K20xはDGEMMでも結構いい性能が出るらしいし、当然1位を狙ってくるはずだ。

さて、本書は以前取り上げた姫野さんと同様にスパコン啓蒙本なのだが、京のお膝元と仕分け人という立場の違いがある。私は金田先生がなぜ京にダメ出ししたのか、その背景にどんな問題提起があったのかしか興味がなかったのだが、結局、京の何が問題だったかというのは漠然としか書かれていない。同業者から相当叩かれたのではと想像するし、外野としてはその辺のことをぶちまけてもらいたかったのだが、やっぱりそれは無理らしい。京で一時的にLINPAC性能1位になっても、元々プロジェクトが掲げていた目標(1)スーパーコンピューター技術の伝承、(2)競争環境を用意すること、(3)スーパーコンピューター設置環境の整備、(4)人材育成の継続性は達成できないだろう。だから一度立ち止まって計画を立て直すべきということらしい。(2)に関して、米国では常に複数の国プロが走っているが、日本では地球シミュレータ、京のように単発である。これでは厳しいというのは同感。幸いTSUBAMEやT2Kがそれを補っている面はあるが。米国流のマッチングファンドは参考になるか？　また、10PFLOPSのフラグシップを1台作るのではなく、1PFLOPSマシンを10台各大学・企業に作って競争する方が、よっぽど安上がりで業界の発展に貢献すると主張する。日本において中規模スパコンの層が薄いのは、計算機の低価格化と個々の研究者に割と潤沢な予算があることで、こまごました計算機ばかりが増えている事情があると言う。それらを数100TFLOPS規模の計算機に集約して、計算機センターの役割を再考するというのはありかも。でも、現実的には7大学以外の計算機センターはもう成り立たなくなっているのだろうか？　HPCIにぶら下がるのでもいいだろうし、いっそEC2などのクラウドでいいのかも。どちらにしろ、ヨーロッパ（や韓国）のように、スパコン開発はあきらめ、コストパフォーマンスのよい計算機を買ってきて、自分たちはソフトウェアの開発に注力するというのは一つのモデルである。わからないことはないけど、ここでレールから降りると、2度と復活できないのではないだろうかという危惧を感じる。走りながら考える必要があるのではないか。

そのほか、教科書ではなかなか知ることができない政治的な事情も書かれていて、その点を面白く思う人がいるかもしれない。7大学計算機センターの生い立ちとか、政府調達でスパコンの定義が1.5TFLOPSに定められている理由とか。スパコンを持っている大学は限られているし、コミュニティの近くにいないとこの辺の事情は（調べようと思えば調べられると思うが）わからない、というか、そもそも興味も持たないか。

話は変わるが金田先生には専門の円周率計算を中心に計算機の歴史について語る本を書いてもらいたい。HITAC 5020、SR2201、SR8000とか日立中心になりそうだけど。

あぁ、時差ぼけのぼ〜っとした頭で文章がまとまらないが、この辺で。

関連：

• メーカーと大学。 長すぎる蜜月が引き起こした必然的帰結　from 『WIRED』VOL. 3

（追記：2012-11-12）最新のTOP500が発表になり、Titanが17.59PFLOPS（ピークは27PFLOPS強）で1位になった。これで京は3位。噂によると今回はGPUしか使ってないらしいし、実行時間も1時間未満だったとか。ノミネートにギリギリ間に合ったという感じなのかな。

スパコンとは何か (ウェッジ選書46)

seek(2)のwhence引数の謎

久々にUNIXネタで、seek(2)の変遷について調べてみた。seekの変遷というと、最大ファイルサイズの拡大にしたがってlseek()、llseek()といった具合にアドホックにシステムコールが追加されている、って話と思われるかもしれないが、違う。今日は第3引数のwhenceについて考えてみたい。

NAME
     lseek -- reposition read/write file offset

SYNOPSIS
     #include <unistd.h>

     off_t
     lseek(int fildes, off_t offset, int whence);

whenceには、offsetの基準点となるSEEK_SET、SEEK_CUR、SEEK_ENDを指定するのはご存じの通り。最近のOSでは、SEEK_HOLEとSEEK_DATAが追加され、スパースファイルを効率的にシークできるようになった*1。が、そんな近代の話ではない。UNIX V6は512バイト単位でシークすることができた。SEEK_SET、SEEK_CUR、SEEK_ENDが0、1、2で、512バイト版が3、4、5となる。UNIX V1のmanページによると0〜2しか載ってないし、V7も同様である。どうもV4からV6の時期にだけ512バイト単位でシークする機能があったのだ。

なぜか？　どんなコマンドでこの機能を使っているか調べてみると、dump&restorやmkfsなどがヒットした。raw i/oはセクタ単位（512バイト）で実行する必要があるので、それが関係するのかも。しかし、正直オフセットを512倍すればいいだけなので、こんな機能いらない気がする。また、デバイス依存*2なパラメータを見せちゃうのは抽象化の観点からもいまいち。kenとdmrもそう考えて、V7ではこの機能を削ったのかな。

*1:Solarisが最初で、Linuxは3.1で対応。

*2:@koieさんに指摘されたが512バイトはブロックサイズだから、デバイス依存とまでは言わないか。

Windows 8でHyper-VならぬVirtualBox環境を構築

盛り上がっているのかどうなのか知らないけど、Windows 8が発売になった。私はボリュームライセンス版を手に入れていて、ここ1週間ぐらい使っている。あまりWindows的な使い方はしてないが、やったことを忘れないようにメモ。

毎日持ち運ぶにはrMBP15はちょっと辛いので、Core duo世代のVAIOノート(VGN-G3)を引っ張り出してきた。CPUはSU9300で、VTには対応しているけど、EPTには未対応。最初はWindows 8 (64bit版)にHyper-V 3.0入っているので、それでLinuxでも動かそうかと考えた。しかし、動作にはEPTが必須なので、あきらめてVirtualBox 4.2を入れてUbuntu 12.04を動かしているが、サクサク動いていて十分使い物になる。

まずはWindows環境の整備から。BIOSでIntel VTを有効にする。WindowsにはVirtualBox以外にEvernoteとCaps LockをCtrlキーにするためのctrl2capだけをインストールした。EvernoteのデフォルトフォントはMS明朝でいまいちな美しくないので、メイリオにしてみた。あとDropboxぐらいは入れておこうかなと思っている。あくまでメイン環境はrMBP15なので凝ったことはしない。

次にUbuntu環境の構築について。サーバエディションをベースに最低限の開発環境を用意しておく。サーバエディションにはデスクトップ環境が含まれていないが、コンソールだけというのも味気ないので、デスクトップマネージャとしてタイル型のawesomeを入れる。Windows 8のメトロUIってタイルっぽいよね。ターミナルはurxt。フォントにterminus。

$ sudo apt-get install awesome lightdm-gtk-greeter rxvt-unicode-256color xfonts-terminus

awesomeの設定はネットで調べてお好きなように。Mod4キーにWindowキーを使うので、いくつかWindowsの処理とバッティングする(Mod4+lとか)。urxvtの設定は.Xdefaultsに記述する。

Rxvt*scrollBar:         false
Rxvt*secondaryScroll:    true
Rxvt*saveLines:         65535
Rxvt*font:       xft:Terminus:8
Rxvt*cursorColor: snow
Rxvt*background:  black
Rxvt*foreground:  white

Windowsとのフォルダやクリップボードの共有を有効にするために、VirtualBox Guest Additionsをインストールする。何が問題なのかわからないけど、VirtualBoxのメニューからISOイメージがmountできないので、次のように手作業で行った。Windows 8固有の問題だろうか？　まぁ、そのうち直るだろうね。

$ mount /dev/sr0 /media/cdrom
$ cd /media/cdrom
$ sudo sh VBoxLinuxAdditions.run

これでリブートすれば、OK。

あとは必要な開発環境をインストールする。

$ sudo apt-get install build-essential git autoconf libtool

最低限と言いつつ、この時点でディスクを1.7GBぐらい使っているけどね。。。

追記：し、しかしですね。Windows 8にSymantec SEP 12をインストールしたら、ブートしなくなってしまいましたさと。再インストールはWindows 7でいいや。
追記２：ディスプレイの解像度を変更するときは、xrandrが使える。例えば、xrandr --output Virtual1 --mode 1920x1200とか。

Open vSwitchの存在意義はOpenFlowだけじゃない

最近、Open vSwitchについて調べたことを、某所でお話しする機会があったので少し忍ばせた（「I/O仮想化最前線」）。スライドのP37から数枚がそう。

Open vSwitchはOpenFlowに対応したソフトウェアスイッチということで大いに注目を集めたし、自分もそのコンテストで理解していた。だけど、おそらく最初からOpenFlowスイッチを作ろうという目的があったわけではなく、VMをホスティングするためのまともなソフトウェアスイッチが欲しいということでプロジェクトが開始したんじゃないかな。あまり昔のドキュメントが見つからなかったので、本当のところはわからないけど。

例えば、VLANを使ってテナント毎にトラフィックを隔離したいと場合も、レガシーブリッジよりも簡単に実現できる。add-portするときにtag引数を追加するだけだ。

# ovs-vsctl add-br br0
# ovs-vsctl add-port br0 eth0
# ovs-vsctl add-port br0 tap0 tag=101
# ovs-vsctl add-port br0 tap1 tag=102

これでVMから出るトラフィックにはそれぞれのVLAN IDが付加され、VMに入るトラフィックからはVLAN IDが削除される。つまり、ゲストOS (VM)ではVLANの設定を気にする必要はない。

また、話は変わるけど、最近CloudStackを触っている。CloudStack 3.0ではOpen vSwitchを使っているものだと思っていたけど、少なくともハイパーバイザがKVMの場合は、レガシーブリッジを使っているようだ。なんでだろう？