Realtime System Benchmark（その１）
以前のLinux 2.6 Real Time Kernel、Restricted hard realtime（その１）、Restricted hard realtime（その２）の記事でも一部触れたが、まず予備知識として、これから登場するPREEMPT_RTとAdeosについて簡単に紹介する。
PREEMPT_RT
カーネル2.6のカーネル・プリエンプションを実装したIngo Molnarを中心に、引き続いて将来のメインライン・カーネルにリアルタイム機能を実装する目的で、リアルタイム拡張機能が開発されている。以前これは、通常のカーネルと比べて明示的にプリエンプトを増やすPREEMPT_VOLUNTARYオプションを持っていたために、voluntary-preemptと呼ばれたが、最近の開発ではリアルタイム機能を追加したPREEMPT_RTオプションを持つため、区別してPREEMPT_REALTIMEとも呼ぶ事もある。ここではこのPREEMPT_RTオプションによるリアルタイム機能を有効にした事を指している。最新のカーネルに対応したパッチは、Ingo Molnarのダウンロードページで提供されている。
Adeos
Adeosは、ミラノ工科大学航空宇宙学部が開発している、マイクロカーネル方式でリアルタイム機能を実現するRTAI（Real-Time Application Interface）プロジェクトのカーネルとして採用され、有名である。Linuxカーネルへのパッチ形式で提供されているため、Adeosは最近各所で、単独で評価されているようである。Adeosはオペレーティングシステムを置き換える、従来方式のマイクロカーネルとは異なり、ハードウェアとオペレーティングシステムの間を介在するレイヤとして実装されるため、開発者らはナノカーネルという呼び方をしている。ダウンロードページから、各バージョン、各アーキテクチャに対応したバージョンがダウンロード可能である。
PREEMPT_RT vs ADEOS: the numbers, part 1
６月１０日にKristian BenoitとKarim Yaghmourが連名で、このタイトルのメールをLKML(Linux Kernel Mailing List)にポストした。
ここ数週間の間、我々はPREEMPT_RTとAdeosナノカーネルの比較テストを行なっている。以前の議論から明らかなように我々は、片方を推奨することが間違っているのかという検証については、未解決のままだった。従ってこの比較は、バニラLinuxと比べた場合の、各実装手段の効果を理解するために行った。
今回は、行った様々なテストランの要約した結果を公表している。そこには勿論、準備のために必要な多くのバックグラウンド情報がある。来週の初め頃に、それを利用可能にするつもりだ。それまでの間、考慮するための材料を以下に提供する。
テストでは、３つのマシンをセットアップして使用した。2つのメインシステムは、FC3でP4 2.8の(SMPではなくUP設定の)Dell PowerEdge SC420だった。１つは256MBのRAMで、モルモット(つまり機械的な動きを実行するマシン、別名TARGET）用だった。512MBのRAMがあるもう片方は、モルモットの反応に関するデータ収集のために使用した（別名LOGGER）。 ３番目のマシンはApple PowerBook 5,6 G4 / 1GBで、２つの目的に使用した。最初それはssh経由で、targetとしても、loggerとしても使用され、そしてtargetへのping floodのためにも使用された。この3番目のシステムは、HOSTと呼ばれる。
すべてのシステム上でデータが生成された：
TARGET: LMbenchデータ※
LOGGER: Interrupt応答時間
HOST: LMbenchの合計実行時間※
※訳注：LMbenchは、Unix系OS用のデータ操作、システムコールやコンテキスト・スイッチング等を計測するベンチマーク・ツールである。
hostとloggerは固定のカーネル・コンフィギュレーションとした。loggerはtargetのトリガと厳密な反応測定のために、adeos対応のカーネルを実行していた。hostは、通常のgentooベースのカーネルを実行していた。targetとloggerは、loggerからの出力がtargetの割込みを起こし、それがまたlogger自身への割り込みとなるように、それらのパラレルポートで繋げていた。
様々なテストランでは、２組のデータを集めることを試みた。１つは与えられたセットアップ環境でのLMbenchの合計実行時間で、もう１つはシステムの割込み応答時間である。両方のテストは、適切な場合には同時に行った。そうでない場合、別々に行った。次の表でそれがわかるはずである。
LMbenchテストランについては、3つのパスで行い、その平均実行時間を収集した。3つのパスは確かに、我々が望むような作業量ではないが、直接的な目的である分析のためには、十分に確証されたデータを提供するはずである。
割込み応答時間測定については、loggerは500,000〜650,000の割込みを生成し、targetの応答時間を測定した。loggerでは、別名”ruby” hardとして知られるhard-rtを実現するAdeosドメインのロギング・ドライバと、データ記録のためのユーザスペース・デーモン以外は、少しも負荷が無かった。Adeosの使用が、正確な応答時間の算出にはペナルティとなるかも知れない。しかしこのペナルティは、すべてのデータに課されている。また、その影響の検証については、以下に示すadeos-to-adeosの分析により推測することができる。
大変な労力だったが、我々が得た結果を示す。前述のようにいずれ、関連するスクリプト、パッチおよびドライバをすべて公開するが、その結果としてみんなは、自分自身のテストを行なうことができるようになるだろう。
注意して欲しい。我々はテストにおいて、同様のカーネルを使用するように、できる限り、試行し、運用してきた。しかしながら、両方とも同じ最新のカーネルにきっちり当てはまる、最新のAdeosおよび、最新のPREEMPT_RTパッチを見つけることができなかった。従ってバニラ2.6.12-rc2をadeosパッチと、2.6.12-rc4をPREEMPT_RTパッチとで比較した。以下のように、バニラrc2およびrc4の実行では、大変似通った結果数を出している。そのため等価であると考えて、合理的だろう。
LMbenchの実行時間
| kernel | plain | IRQ test | ping flood | IRQ & ping | IRQ & hd |
|---|---|---|---|---|---|
| Vanilla-2.6.12-rc2 | 174 s | 175 s | 189 s | 193 s | 217 s |
| with Adeos-r10c3 | 180 s | 180 s | 185 s | 183 s | 211 s |
| % | +3.4 | +2.9 | -2.1 | -5.2 | -2.8 |
| Vanilla-2.6.12-rc4 | 176 s | 177 s | 189 s | 191 s | 218 s |
| with RT-V0.7.47-08 | 184 s | 187 s | 206 s | 201 s | 225 s |
| % | +4.5 | +5.6 | +9.0 | +5.2 | +3.2 |
凡例：
| plain | = 何も特別な事はしない |
| IRQ test | = loggerで： 1ms毎に targetにトリガ |
| ping flood | = hostで： “sudo ping -f $TARGET_IP_ADDR” |
| IRQ & ping | = 上記２つの組み合わせ |
| IRQ & hd | = IRQ testをしながら、targetで：次のスクリプトを実行 “while [ true ] do dd if=/ done” |
以下のように、割込みは1ミリ秒ごとでloggerがトリガとなって起きる。より短いトリガ回数で、このようなテストをやり直すことは興味深いかも知れない。しかしながら、我々はできれば「既製品として」loggerを維持したかったのである。
割込み応答時間（マイクロ秒）
| Kernel | sys load | Aver | Max | Min | StdDev |
|---|---|---|---|---|---|
| Vanilla-2.6.12-rc2 | None Ping lm. + ping lmbench lm. + hd |
15.5 15.7 16.0 15.8 15.8 |
64.8 63.4 72.2 65.6 179.9 |
15.2 15.2 15.2 15.2 15.2 |
1.0 1.2 1.4 1.1 1.3 |
| with Adeos-r10c3 | None Ping lm. + ping lmbench lm. + hd |
13.4 13.8 13.9 13.9 13.9 |
53.3 53.3 21.8 21.3 53.2 |
13.2 13.3 13.2 13.3 13.2 |
0.2 0.6 0.7 0.6 0.5 |
| Vanilla-2.6.12-rc4 | None Ping lm. + ping lmbench lm. + hd |
15.2 15.6 16.0 15.8 15.8 |
64.2 63.0 170.5 184.1 67.1 |
15.2 15.2 16.0 15.2 15.0 |
0.5 0.9 1.4 1.2 1.1 |
| with RT-V0.7.47-08 | None Ping lm. + ping lmbench lm. + hd |
15.5 17.1 17.7 17.1 17.0 |
73.8 79.8 77.2 80.0 80.0 |
15.2 15.2 15.2 15.3 15.3 |
1.2 2.3 3.1 2.3 1.8 |
凡例：
| None | = 何も特別な事はしない |
| ping | = hostで： “sudo ping -f $TARGET_IP_ADDR” |
| lm. + ping | = 前項テストと、targetのlmbench-2.0.4/src/で： “make rerun” |
| lmbench | = targetのlmbench-2.0.4/src/で： “make rerun” |
| lm. + hd | = 前項テストをしながら、targetで：次のスクリプトを実行 “while [ true ] do dd if=/ done” |
注意： Adeos-r10c3は、AdeosとPREEMPT_RTの両方を含む「複合」パッチであるが、PREEMPT_RTは無効にしている。
上記データは今のところ、分析無しでそのまま提供するものである。完全なデータと関連するソフトウェアを公開する時に、これの分析結果を用意するだろう。今のところは、この結果がさらなる反響を手助けするように望んでいる。
反響と続き
I/Oスケジューラの開発で有名なNick Pigginが答えた。
これは素晴らしいデータである。作業をしてくれて本当にありがとう。私は、このスレッドとこのトピックに関する将来のスレッドを、技術的事実と数値結果の方にもっと導くことができればと望んでいる。なぜなら、それが健全な選択を行なうただ一つの方法であるからだ。
ほかにもKristianのポストに対しては多くの反響があり、この後も彼らは引き続いてテストを行って行く事になるのだが、続きは次回という事にさせて頂く。
参考情報
なおKristianは、以前紹介したKarim Yaghmourと同じopersys Incのスタッフである。Karim Yaghmourは特にAdeosの開発メンバに名前が載っていて、彼のopersys IncはAdeosプロジェクトに積極的に関わっている。ほかにもLinuxのリアルタイム拡張の実装例がある中で、Adeosだけをいわば正統派のPREEMPT_RTにぶつけて評価しているのは、Adeosが最新のカーネル2.6を対象に開発されているからという理由もあるだろうが、前回の流れからするとコマーシャルくさく感じてしまう。
いずれにしても彼らの成果（実体はLKMLにポストしたメール）と使用したツールキットは、すでにLinux RT Benchmarking Frameworkのページで公開されている。まだ筆者は試してないが、早速使ってみることも可能な様子である。
