Ottawa Linux Symposiumは世界中からLinux開発者が集まる,年に一度のカンファレンスである。今年もカナダのオタワで,6月27日から30日の4日間開催された。
Ottawa Linux Symposium会場(写真提供:NTTデータ 原田季栄氏) |
今年からKernel Summitの開催がLinux Symposiumとは別に開催されることになったので,Linus Torvalds氏やAndrew Morton氏など何人かの重鎮の出席はなかった。その影響か,参加者総数は750人程度で,昨年より若干減少した。しかし日本からの参加者は昨年より増え,主に大手ハードウエア,SIベンダーなどを中心に60~70人程度参加していたようである。
会場は800名ほど入るキーノートスピーチ用の部屋から100人程度の小さい部屋まで5つあって,並行してセッションが開催される。日本からは日立製作所の平松雅巳氏と大島訓氏,NECの上田氏とNECソフトウェア東北の佐藤尚氏、私 ミラクル・リナックスの吉岡弘隆が発表したほか,NTTデータの原田季栄氏らが開発したTOMOYO LinuxのBOF,PLAYSTATION3で稼働するLinuxのBOF(SCE 塚本氏による囲み記事参照),NTTの小西氏,Googleの河内氏などによるBOFがあった。
筆者が出席した,興味深かったセッションを紹介する。セッションのタイトルをクリックすると,講演概要のPDFがダウンロードできるようになっている。
Gregは,Linux カーネルの開発の定量的な側面について報告した。カーネルのソースコードサイズは年率10%程度増加しており,現在(2.6.21)は800万行程度である。カーネルのリリース頻度(70~100日),リリースごとの変更数(4000~7000),一時間あたりの変更数(2.1~4.1),変更の個所などのデータを示した。
各リリースごとの開発者の数は,2.6.11が479人で2.6.21は838人,合計で約3000人が貢献している。また会社数は83社である。個人ごとの集計では,Al Viroがトップで,David Millerが続く。所属では,Red Hat,Novel,Linux Foundationが多いがトップは個人となっている。今だに,多くのパッチが個人によって作成されているという事は興味深いところである。なお,彼のリストにはMiracle Linuxの名前がないが,集計用スクリプトの不具合かと思われる。
エンタープライズ向けのワークロードの特徴をマルチコア環境で考察した。シングルコアでの動作との主な差は,カーネルの実行時間に占める割合が増加傾向にあって,かつてはユーザとカーネルの実行時間の比率が80対20程度と言われていたが,現在では64/33/3くらいとなっていて空も3%くらいある。カーネルの実行時間が増加傾向にあるのは,キャッシュのアクセスコストの増加による。
最近のマルチコア・プロセッサは従来の対称型マルチプロセッサと異なり非対称なマルチプロセッサ(NUMA)である。NUMAの場合,ローカルなキャッシュにアクセスするのは速いがリモートのキャッシュアクセスは遅い。異なるノードからの読み込みが極めて遅いため従来の方式では性能が向上しない。
Coreyらは,Oracle 10g Release 2でOLTP workloadで測定し,キャッシュのfalse sharingとして知られる性質の悪い動作を観測している。キャッシュラインの分析によりリクエストキュー(rq)にキャッシュの競合などを発見した。
従来のSMPから,NUMAになるとメモリレイテンシの顕著な増加がみられるので,それの対処が求められている。
Googleのようなサイズのクラスタシステムの運用とトラブルシューティングの難しさについて議論している。
OracleのBrown氏による非同期システムコールの話である。Async I/O(非同期I/O)はI/Oの完了でブロックしないでユーザランドへ制御が戻るのでスループットをあげるのに利用されている。それをより一般化し,システムコールの完了を待たないで,ユーザランドへ制御を戻す方法について議論している。通常はユーザアプリを変更する必要があるがIngo Molnarのsysletというメカニズムを提案し,その敷居を下げた。sysletを利用したユーザアプリのベンチマークを紹介していた。
日立の平松氏と大島氏のdjprobeの発表は小さい部屋ながらいっぱいの盛況であった。probeを埋め込む方法としてint3(割り込み命令)を入れる従来の方法(kprobe)に対し,jmp命令を入れる方法を提案している。djprobeは性能的な優位性だけではなく,割り込みが発生しないので,コンテキストスイッチが発生しないため,様々な利点が考えられる。
コンピュータの歴史をメインフレーム時代からミニコンピュータ,タイムシェアリング,PCへと概観し,普通の人が使うには,PCですら様々な問題をはらんでいる。そこでLTSP (Linux Terminal Server Project) を提案している。シンクライアントはサーバ側が管理を行なうので,セキュリティ問題や,バックアップ等の問題がない。また安く製造できるので,発展途上国での利用もみこめる。インターネットの接続性を世界中に提供すること,フリーソフトウエアを奨励することなどのビジョンを語っていた。
TOMOYO LinuxのBOFではSELinux,LSM,AppArmorなどセキュアOS関連の開発者が勢ぞろいし,活発に議論をおこなっていた。メーリングリストだけだと顔が見えないし,どのような思いで開発をしているかなどが伝わらないが,実際に会って議論すると,メールで議論するよりも遥かに濃い議論ができるし,その後のメールのやり取りがスムーズになる。そのような事をTOMOYOチームは実体験されていた。いらないお世話かもしれないが,日本企業発のオープンソースソフトウエアがコミュニティとのコラボレーションをする時の一つのケーススタディになれば面白い。
TOMOYO LinuxのBOF(写真提供:NTTデータ 原田季栄氏) |
実はTOMOYO LinuxのBOFがOttawaで行われるきっかけは,著者の主宰するカーネル読書会だった。読書会で発表してもらった時に,参加者から「Ottawaに行って発表しましょう」というコメントが出た。その声に押され,TOMOYO LinuxのチームはOttawaでのBOFに申し込みを決意した。そのような経緯もあり,筆者も楽しみにしていた。
BOFの詳細は,TOMOYO LinuxプロジェクトのWikiに詳しいので,ご参照いただきたい。
http://tomoyo.sourceforge.jp/wiki/?OLS2007-BOF
自分の発表である。最終日の昼食時というタイムスケジュールだった。英語で発表するという事と言うよりも,発表会場の広さに若干たじろいだ。
筆者の発表(写真提供:NTTデータ 原田季栄氏) |
crackerjackというリグレッションテスト(プログラムを変更した際に,その変更によって問題が発生していないかを調査するテスト)のフレームワークと,btraxという分岐カバレージ計測ツールについて発表した。btraxはIA-32が持つブランチトレース機能を利用して,条件分岐のどちらを実行したかをカーネルの再コンパイルなしに精密に計測できる。カーネルテストプログラムを実行しbtraxで分岐カバレージを計測すれば,カーネルのどの部分を実行し,どの部分を実行していないかが分かるので,テストによって実行されていない部分(テストされていない部分)が一目瞭然で発見できる。その情報を基にテストプログラムを改良していけば,よりカバレージの高い,すなわち,より良いテストになる。
カーネルのリグレッション・テストは今後も重要性が大きくなる分野だ。コミュニティとのコラボレーションをどのように取っていくかが課題になる。
進化と多様性というタイトルでキーノート・スピーチがおこなわれた。フラグメンテーションというのは,フォーク(分岐)として知られているが,それは多様性の観点からは悪い事ではない。むしろ進化には,そのようなものが必要である。またクローズドソース・ドライバについては,それは不道徳というより,ベンダーおよびユーザーにとってコストに見合わない,ばかげたアイデアであると述べた。
まとめ
Linuxの開発者の祭典であるOttawa Linux Symposiumに3年ぶりに参加した。日本人参加者が増えていたのが印象深かった。特にハードウエアベンダーからの参加者が急増していた。当面この傾向は続きそうである。
一方で,オープンソースのエコシステムに対する当事者としてのビジョンの提示やコミットメントをする,James BottomleyやJon 'Maddog' Hallのようなビジョナリが,われわれの地域から登場していない事に,一沫の寂しさを感じる。技術の開発だけではなく思想的な先導者も日本に必要なのではないか,というのが今回の感想である。
なお,わたしのブログ「ユメのチカラ」でも現地からの報告を記した。興味のあるかたは御覧いただきたい。
OLS 2007 (3) -- TOMOYO Linux BOF
Ottawa Linux Symposium 2007 (ols2007) まとめ
■付録 発表者の所在地が国旗で示されているので,国別に集計してみた。 |
|||||||||||||||||||||||||||||||||
|
|||||||||||||||||||||||||||||||||
となり,米国が圧倒的に多い。 | |||||||||||||||||||||||||||||||||
|
|