Japan Linux Symposium 2009：2日目（10月22日）のセッションメモ

Measuring Function Duration with Ftrace

資料はこちら。
Ftraceによる、関数の実行時間測定や、起動時間測定の事例紹介。
カーネルの全関数を追跡可能。
- オーバーヘッドの少ないmcount()ルーチンが全関数の入り口で呼ばれている。
- 出口のトレースのメカニズム。スタックの戻りアドレスをトレーサーの処理関数に置き換えて実現している。
使い方
- debugfsをマウントして情報取得。
- トレースデータの解析”fdd tool”
  - 関数のカウント、総実行時間、durationの平均の取得。最も長いduration、それが何回呼ばれたかに注目。
起動時間測定の例
- カーネルコマンドラインオプションで設定。
- トレーサは、カーネルコア（タイマ、メモリ、割り込み）を初期化した後に動く。今回の評価環境（ARM）では、start_kernel()のあと、50ms後ぐらい。
- 測定ポイントを外れたら、トレースを止める必要がある。この例では、pty_initで止めてた。
トレースのオーバーヘッド
- 3.22usぐらいがトレース関数の平均。11.4us、関数ごとにかかる。
参考
- http://www.atmarkit.co.jp/flinux/rensai/watch2009/watch03a.html

Statistics of Linux Kernel Development

Linuxの開発にまつわる様々なデータをまとめたお話。Linuxの動きを統計的側面から知る。

現在のLinuxカーネル
- 11.9ML
- 409K　Files
- 今年だけで18%の増加と4バージョンリリース
- パッチ投稿数：1291パッチが2..6.31でマージされた。2.6.15の2倍である。
vger.kernel.org　には141メーリングリストがある。
- LKMLには5491人の登録，サブシステムにも同じぐらいの登録者。
- 31594人のメンバーが141のメーリングリストにいるて、開発に参加している。

メンテナの数
- 2.6.31には767メンテナがいる。2.6.10からソース行数と同じように、メンテナの数も2倍になっている。

開発プロセス
- マージのやりかた
  - Linuxリリース後、2週間のマージウィンドウが開かれる。この期間に新機能をマージする。そのあと、RC版が1週間から10日周期で8-9回ほどリリースされる。
- Linux-next
  - 144のサブシステムが、次のマージウィンドウに向けて、管理されている。ここでは、メンテナがテストしている。（自動のデイリービルドなど。）
- Stable release
  - リリース後の、バグフィックスとセキュリティフィックスが組み込まれる。カーネルバージョンの4つ目の数字としてカウントアップされる。（例）2.6.11.1
  - 次のLinuxバージョンがリリースするまで開発が続けられる。

コードの増加
- 1バージョンで2〜5%のコード増加
- 最近の4バージョンで1.85ML増えた。
- Patch
  - ソース行数の10〜20％にあたるpatchが削除・追加されている。

Does Linux bloated and huge?
- 行数の半分以上はDriver
- 23%はarch
- 8%はinit
- つまり、コアの部分は割合として小さくなってきている。ハードウェア依存の部分だけが広がっている。（自然な膨張である）
- コンフィグレーションファイルの増加
  - Kconfigは610個。最近4バージョンで40ファイルが追加された。
  - configアイテムは、9200（2.6.31）。configオプションは、バージョンごとに300-400増えている。3-4%の増加。（思ってたより多い！）

ディストリビューション
- カーネルリリース後、6-7か月後、テストとインテグを経てリリースされる。新しいバージョンは2-3年毎にリリースされる。（Fedora，SUSEの例）
- カーネルのバグフィックスなどを取り入れるので、このようなサイクルになる。

Suggestion
- 自分でLinuxを構築するのは現実的でない。1300人のハッカーとあなたのチームを比べてみてください。コードをメインラインにマージしよう
- QAや、情報もコミュニティを活用すれば、素早く、小さなコストで情報が入る。
- エンジニアの教育になる
- すごいエンジニアがコミュニティにいる。開発のプロセスも身につく

- コミュニティに参加しよう！
  - HOWTOドキュメントからはじめる
  - 日本語化などでも貢献できる。

Seven challenge for th kernel community(aka The Kernel Report, JLS 2009 edition)

Jonathan Corbetによる、恒例の「Linux Kernel Report」。
＃生で観れてよかった！
Linus Symposiumの前に行われていたカーネルサミットのお話なんかもちょっと聴けたりして、最近のカーネルの動向を、最も正確かつ端的に知ることができるセッションです。

バイタリティ
- 2.6.27→2.6.31の変更点概要
  - 53000の変更点
  - 2500人の開発者
  - 400人の社員
  - 300万コードに相当する増加
  - 142の変更セットが毎日行われた。毎日7750ライン。
- 開発に関わっている企業は数多くある。
  - 日本の企業の貢献も高まっている。

各バージョンで追加された主要機能
- 2.6.27
  - Ftrace
  - UBIFS
  - Multiqueue networking
  - gspca video driver set

- 2.6.28
  - GEM graphics memory manager
  - ext4 is no longer experim ental
  - "-staging tree"→新機能の実装が早くなった。
  - Wireless USB

- 2.6.29
  - Kernel mode setting
  - Filesystems（Btrfs，Squashfs）
  - WIMAX support
  - 4096 cpu

- 2.6.30
  - TOMOYO Linux
  - Integrity measurement→システムのインテグリティ、システム脆弱性の評価
  - R6xx/R7xx graphics support
  - Nilfs

- 2.6.31
  - Performance conter support
  - Char device in user space
  - Kmemleak
  - TTM and Radeon KMS support
  - Storage topology

- 2.6.32
  - 12/T release
  - Lots of block scalability work
  - Performance counter improvements
  - Scheduler interactibity work
  - Shared memory

カーネルサミットの話題
- 大きな変更はしなくても良い。
- （集合写真をみて）みんなちょっと歳をとったな、という印象を持った。（笑）
- 1990年から始まったプロジェクトが続いているが、”New blood” 新しいパワーがいる。

課題
- dcache_lock
  - 10Gbpsはトラフィックの問題がおこる。SSD1秒あたり100000ぐらいになる。少しのオーバーヘッドが大きな問題になる

- Scaling down
  - 電話、カメラなど、ソニーのソースコードを見てください、ドアベルの製品まである。小さいものにも対応していかなければならない。
  - 最小コンフィグレーションのカーネルのソース行数のグラフをみると、2.6.29で大きく跳ね上がっている。
  - 最小化では、日本の技術者に参加してほしい！

- Storage
  - ストレージは早くなっていないかもしれないが、大きくなってきている。
  - ext4も安定化に向かっているが、古い仕組みに基づいたものだ。
  - Btrfs。パフォーマンス、スナップショット、RAIDなど、先進的な実装。2.6.29ではまだexperimentalだが、開発が進んでいる。

- Solid-state Storage
  - TRIMのコマンドがうまく実装されていないと、プロセスがdisableされる。
  - SSDは、パフォーマンスを引き出すにはまだまだやることがある。ラッシュを、通常のディスクの枠組みに置き換えてるから、性能が出し切れない。
  - googleが興味をもっている。

Visibility
- いま、システムは何をしているのか、何がおこっているのかを知ることに関心がある。
- DTraceのファンをどうだませるか？
- SystemTap
  - 非常に複雑だし、カーネルコミュニティにあまり関わっていないという課題があった。
- Ftrace
  - レイテンシのトレース
  - ダイナミックトレースポイント
  - カーネルコミュニティで、大きな関心を集めている。
- Perf Events（旧PErfcounter）
  - レジスタモニタリング
  - トレースポイントと統合すると便利
- LTTng
  - 非常に良いツールだが、開発者のビジョンが見えてない

Response（リアルタイム）
- 単に早いというだけではない。時間保障をすることだ。（逆に遅くなることも）
- 適用範囲として、組み込みはもちろん、金融サービスのシステムでも求められている。
- リアルタイムでの取り組み
  - リアルタイムプリエンプションパッチ
- ツリー外で、いろんな製品があった。
  - 割り込みのスレッド：Mutexes
  - Priority inheritance
  - レイテンシ削減パッチなどのパッチが、メインライン以外のところで開発が進んでいる。
  - スピンロック、ビッグカーネルロックの削減が課題として残っている。

- Deadline sheduling
  - 現在のLinuxのリアルタイムはプライオリティベース。Deadine sheculingでは、タスクの実行期限を設定する。
  - SCHED_DEADLINE。パッチはできていて、ある程度動いているが、プライオリティの問題が少し残っている。こうした動きがあることを紹介しておきます。

conteinment
- 仮想化
- コンテナ。プロセッサをホストのマシンで分離しておく。実装が大変。
- KSM。KernelSharedMemory
  - ページでduplicateしているところを探す。みつけたら、片方を消して、シェアする。変更はコピーオンライトで書き込む。
  - 2.6.32にマージされる。仮想化では有効なパッチ。

- コンテナ
  - namespaceの問題
  - リソースコントローラー
  - checkpoint/resatartが未対応：コンテナの状態を保存する

ハードウェア
- いまでは、ほとんどのハードウェアが動いている
- 残課題
  - グラフィックカード
  - いくつかのネットワークアダプタなど