Develop and Download Open Source Software

Karim Yaghmourがこう言ったのは、前回のRealtime System Benchmark（その１）の続きの話のことである。

次回へ向けて

Karim Yaghmourは続けた。

それと「dd」テストは正確ではなかったかも知れない。「bs=1m」としておくべきだったからだ。このままだとddコマンドは、実際の負荷を作らないからだ。次回の検査では、これを加えることになる。

私は、既に追加テストの提案があることを知っているが、それは良い事である。我々はできるだけ多くを試しそうとしている。Kristianが組み立てたスクリプトは、比較的単純である。しかしながら我々は、無限のリソースを持ってるわけではない。我々が開発したフレームワークを共有するためには、他の人も自分自身でテストを行なうように、意識することを望んでいる。

一方でカーネル2.6のRealtime機能であるPREEMPT_RTを実装している、Ingo Molnarが聞いた。

PREEMPT_RTテストに使用した.configを私に送ってくれないか。また-47-08を使用したとの事だが、それは現在のパフォーマンス向上よりも前のものだ。従って-48-10か、より良いバージョンで再実行して貰えるといいのだが。

Nick Pigginも追加した。

実際に興味深いのは、様々な他のRTカーネルの中にある、カーネル機能のレイテンシをテストすることである。それは例えば、メッセージパッシング、パイプやlocalhost読み取り/書込み、シグナル、folk/clone/exit、mmap/munmap、共有メモリの中でのメモリフォールト、ほかにもRT関連の人にとって重要なことすべてだったりする。

Ingoは、それらのテストで有効にされたとするデバッグ・オプションが怪しいと伝えた。「PREEMPT_RTのレイテンシ数は、私が同様のボックスで測定したものと比べて具合が悪すぎる。PREEMPT_RTの上のデバッギング機能は強力だが、オーバヘッドも大きい。」彼はまた、テストで使用される.configファイルを再び(実際には３度目になる)求めた。どのオプションに注目すべきであるかを伝えるために、最も容易な方法だからである。

Karimは.configファイルをポストした。それに対してIngoは、レイテンシを増加させている多数のオプションを指摘し、48-11用の修正版をポストした。KarimはIngoが修正した.configファイルを新しいテストに使用すると伝えた。

James R. Bruceは、最低のレイテンシで使用するための最良のオプションを、 (例えばDocumentation/rt-preemptのような形で)文書化するようにIngoに依頼し、Ingoはそれに答えた。「同意するので、これを導入しよう。最新のパッチ(-48-17以降)ではデバッグ・オプションのデフォルトをオフにするように変更した。もし.configが既にデバッグ・オプションつけていたならば、それらはオフにはならないが、新しいテスタのための.configsではそれらをオフにする。また私は、一定の大きなオーバヘッドがかかるデバッグ・オプションが有効な場合、次のような目立つメッセージをブート時に加えた：

*****************************************************************************
* *
* WARNING, the following debugging options are turned on in your .config: *
* *
* CONFIG_DEBUG_RT_LOCKING_MODE *
* CONFIG_RT_DEADLOCK_DETECT *
* CONFIG_DEBUG_PREEMPT *
* CONFIG_CRITICAL_PREEMPT_TIMING *
* CONFIG_CRITICAL_IRQSOFF_TIMING *
* CONFIG_LATENCY_TRACE *
* CONFIG_DEBUG_SLAB *
* *
* they may increase runtime overhead and latencies considerably! *
* *
*****************************************************************************

文書化については、「私は偉大な文筆家でも医者(Doc)でもない。私は絆創膏（Patch）を扱っているに過ぎない :-)」と答えた。

PREEMPT_RT vs I-PIPE: the numbers, part 2

10日後の6月10日に、Kristian Benoitが2回目のテスト結果をポストした。

我々は、テストの第2ラウンドをやっと完結することができた。不運にもこれは、予想よりとても長くかかってしまった。詳細に立ち入らないで言うと、意図した通りのテスト設定をするために、個々の問題に陥っていたのである。幸いに結果は興味深く、我々が望むように、比較しているアプローチの性能をより正確に示している。セットアップは以前に記述したものと全く同じである。従って、もし最初の初期のポストを見ていなければ、背景を知るために、最初にそれを読みに行くほうが簡単だろう。

PREEMPT_RTについては、Ingoからの言葉により、前回のテストで使用していたバージョンから多くのものが修正された。従って我々は、より最近のバージョンを使用し、Ingoによって用意された.configを頼った。また確かに測定数値は、Ingoの分析の通りだったと思われる。以下に示すように、PREEMPT_RTはとてもよく動作している。

Adeosについては... そもそもAdeosとは何だろうか。今回、私が仕組んだのはI-pipeであり、まさにこれに関するニュースがある。我々がAdeosプロジェクトのPhilippe Gerumの成果のベンチマークテストに取り組んでいる間、彼は実装していた割込みパイプライン（Interrupt pipeline）を分離するために、Adeosパッチのコア部分を再度組み直した。このパッチに関するPhilippeの最新のポストが、より良い説明をしている。基本的には、我々がAdeosで使用し、測定したものは分離されたI-pipeと同じもののはずである。先週の金曜日（6月17日）にPhilippeがLKMLにポストしたバージョンは、テストに使用したものより最新であるから、より良い結果が出るかも知れないが。

I-pipe: Introduction

という訳で早速、6月17日にPhilippe Gerumが、「[PATCH 0/2] I-pipe: Introduction」というタイトルでLKMLにポストしたメールを紹介する。

過去5年間、私はLinuxの様々なリアルタイム・ソリューションに取り組んでいる。この関わりの一部としては、Adeosナノカーネルとして知られているものの開発と、RTAIの再構成と、プロジェクト内で「Fusion」トラックとして知られているRTAIの再実装であった。次のステップにこの作業を引き上げ、かつさらにメインストリーム・カーネル開発での共同作業、および統合化を増進させるため、Linuxのための割込みパイプラインとしてパッチセットを紹介する。

I-pipe(省略形)は、Adeosの実装に含まれていた割込みパイプラインを取り出したバージョンである。これはLinuxへの限定的な統合ではあるが、フルバージョンのAdeosで可能だったように、Linuxで並行動作する実行部分を実装する機能を含み、Adeosに由来する多くの同じプロパティを保持している。

重要なことは、このパッチは余計な追加や修正のないLinuxカーネルで、厳密な割込み応答時間を得ることが可能だということである。 例えばドライバは、Linuxの優先割込みドメインの一部としてハンドラを登録し、その後Linuxコードのいずれかの部分が割込みを無効にしたかどうかにかかわらず、厳密な方法でその割込みを得る場合がある。またそれは、「Fusion」でフルに統合された例のように、Adeosの残骸が複数の実行部分がLinuxと並行して走ることを可能にするために、I-pipeの上にそれ自体をロードすることを可能にするような、機能の積み重ねを作成することが比較的簡単にできるはずだ。

基本的にI-pipeは、割込み管理ハードウェアとLinuxの間にそれ自身を挿入する。割込みを無効にする何らかのLinuxコンポーネントの何らかの試みは、LinuxのI-pipeステージでストールさせられる。ストールの間、パイプライン・ステージは割込みを受け取らない。しかし自身のステージでストールし続けない限りは、より高いプライオリティの何らかのパイプライン・ステージが割込みを受け取り続けるだろう。その結果、割込みはほとんど無効にならないことになる。

私は、コアセットの変更点とx86アーキテクチャ依存の実装にパッチを分類した。変更点は主にI-pipeを実装する、次のファイルの追加である：

• include/linux/ipipe.h
• include/asm-i386/ipipe.h
• ipipe/*
• kernel/ipipe.c
• kernel/ipipe.c
• arch/i386/kernel/ipipe.c

以前、AdeosとPREEMPT_RTの両方を含む組み合わせパッチの有効性が実証されたので、このパッチがPREEMPT_RTでも活用できることに注意して欲しい。そのため、PREEMPT_RTに興味を持っている人にも、I-pipeパッチをレビューすることを奨励する

I-pipeはその後何回か改良を積み重ねて、PatchがLKMLにポストされている。またx86だけでなくppc32とia64にも対応した。最新版のI-pipeはgnaのAdeosの中にあるI-pipeのダウンロードページから入手可能である。

話を2回目のテスト結果の本題に戻す。

システムの負荷（LMbenchの実行時間）

各３回ずつ実行した平均のLMbenchの実行時間を示す。

凡例：

軽負荷時のI-pipeの性能は、前回のAdeosより良く、負荷がかかっている場合には悪い。これは今回のI-PIPEが、Patchサイズを小さくしたというメリットがあるものの何らかの機能が削除が影響しているかも知れない。

全般的には、I-pipeのシステム性能への影響の方が、PREEMPT_RTよりも低いように見える。

割込み応答時間（マイクロ秒）

凡例：

まずバニラLinuxは明らかに大きな、割込み最大応答時間を持っている。PREEMPT_RTの結果は、明らかに前回よりはるかによい。Ingoの適切な設定オプションと最近の変更が、PREEMPT_RTに有効に働いていると思われる。これは実質的には、I-pipeと同じレベルの割込み最大応答時間に近づいていると言える。また、I-pipeはすべてAdeosと同様の結果を出したように見える。

反応

これを見てまずIngoが言った。

localhostの上のUDPのレイテンシについては、現在のPREEMPT_RTパッチの中で修正されているsoftirq処理のバグがあった。実際のネットワーク上のレイテンシには影響がなかったので、気付かなかった問題だ。テスト結果に影響する修正があったので、どうか最新の（現在の)-RTカーネルを使用して再テストをして欲しい。

Karimが答えた。「この点については、テストのうちのいくつかを再実行せざるを得ないだろう。しかし、誰かが最新の機能を持ってないとか、テスト結果が良くないと主張する度に、何回もテストを繰り返す事はできない。確かに今回のバグフィックスは、オーバヘッドの結果に大きく影響するとは思う。」しかしIngoは、

さてそもそもは、PREEMPT_RTに対するADEOSをベンチマークテストするはずだった。そしてPREEMPT_RTの結果数値が100%以上無効だった一方で、そっちの都合のよいプロジェクトの結果数値をポストした。2番めの結果は引き分けだった。しかしテストにはバグがあったので、我々はまだハードウェア上の正確なPREEMPT_RTのirqレイテンシの値を知らない。従って必要最小条件としては、まず正確な結果数値をポストすることではないか。これから始めてはどうだろう。

LKMLのこのスレッドは、「ベンダがスポンサーであるベンチマーキング」がいかに悪いアイデアであるかという、多くの理由のうちの1つを示している事例である。私だったら、PREEMPT_RTを「他の」リアルタイムプロジェクトと比較するような、ベンチマーク数値をポストしないだろう。なぜならその結果が、みんなから偏見を持って見られるからである。私は最善の策をわきまえているので、自分では他とのPREEMPT_RTをベンチマークテストしないようにしている：）

これに対してKarimが言った。

これは不当な個人攻撃である。4年以上前から私が考えていた、Linuxでのリアルタイム性能を測る方法に関する提案を差し控えるべきだったのだろうか？今回は再試行により、「私の」プロジェクトと、「他の」プロジェクトが同じように良い結果だったことを公表したのだが。そもそもAdeosとPREEMPT_RTをベンチマークテストしたのは、共にバニラLinuxで活発に開発されていて、真のリアルタイムが実現できるPatchだからである。irqレイテンシについては、再テストを約束した。しかし以前にも言ったように、このテストで一番重要視すべきなのはLMbenchの結果である。繰り返すが、使用したソフトウェアはダウンロードして利用可能である。テスト方法に間違いが指摘されれば、われわれは喜んでそれを認める。

Opersysは余分な開発工数を持っていない。現在のテストセットと、すべての関連する人間とハードウェアコストは、実際のところ私個人のポケットから出ている。またこれに代価を払うクライアントはいない。

確かに私は指摘のように、割込みレイテンシでI-pipeと同じくらいPREEMPT_RTが健闘するとは思わなかった。しかしそれでもまだ承服できないならば、別の検査結果を公表するか、我々のどこがどれくらい間違っているかを示して欲しい。あなたは非常に有能な開発者だから、我々の不正行為を示すことは難しくないに違いない。この理由で私は、あなたに対する個人攻撃をこらえている。しかしながら、私は失望した。

この後もさらに泥仕合が続いたのだが、あまり意味があるとは思えないので、この辺にしておく。