SourceForge.JP: Open Source Software

Paul E. McKenneyは今年のカーネル・サミットの直後に開催されたLinuxシンポジウムにおいて、Linux Kernel Scalability: Using the Right Tool for the Job (PDF)と題したセッションを担当していた。Paulからその「Restricted hard realtime」というメールがポストされたのは、前回のSven-Thorsten DietrichのLKMLへのポストから2週間後であった。彼はそれには（驚くべき！）多くの欠陥があることを知っていたのだが、アイデアを示すために部分的なパッチを示した。

それはリアルタイムカーネル拡張を行っているIngo Molnarらによる既存の作業にマージされていないものであった。指定されたリアルタイムCPUは、そのCPUについてのシステムコールの負荷が移動されるように、ハードコーディングされている。すなわちPPCの機能で意図的に、 CPU 0にすべての割込みを割り当てるように整列させようとしている（彼のパッチはPowerPC用だった）。例外処理やTrapではなく、システムコールに関してだけ扱うようになっている。また完全にはテストされていなかった。

しかしそれはリアルなコード（Real Code）だった。Paulはパッチのポストを、次のように締めくくった。

目的はLinuxにおいて、Hard Realtimeへと進化するパスを提供することである。Linuxの中にある可能性は、Hard Realtime応答性を分割させることができ、またそう求められている。そして一方ではHard Realtime応答を必要としない、多くの機能もあるだろう。例えば現在の技術的なトレンドでは、ディスクへの1MBの同期書込みにはある程度の時間がかかり、そして通常のリトライやエラー条件に従うだろう。このようなアプローチでは、その操作がより単純な非リアルタイムコードを持ち続けることを可能にしている。

これは、「クリーンな方法で既に実装されている」とIngo Molnarが指摘した。

Dimitri Sivanichによって実装された「isolcpus=」ブート・オプションとスケジューラ機能をチェックして欲しい。これは、同様の目的のために、「sched-domains」によって1セットのCPUを正確に分離する。このドメインに入る方法はaffinity syscall（実行CPUを同一化するシステムコール）である。また、このようなドメイン分離により、バランスは悪くなる。

Paulはこの作業を知り、喜んで確認した。Dimitri Sivanichのコードを探求した一日後、彼は言った。

「isolcpusのコードがcross-runqueueのロック獲得をすべて取り除くことを自分で証明できていないが、それは確かに多くのそれらを取り除いている。またシステムコールあるいは例外ハンドラの負荷を移すようには見えない。しかしこれは、私がこの種のことをクリアにする方法を助けてくれる。」

Paulが不要な#ifdefを削除するための小さなパッチをDimitriに送ったところ、Dimitriが答えた。「そのコードは元の私のパッチの一部ではなかったが、ちょっと見ただけで、このパッチが的を得ていると確信している。」

一方で、Thomas Gleixnerは全てのものに懐疑的だった。ひとつには彼は、「私はまだ組み込みSMPシステムを見ていない。」と言った。「SMPシステムにフォーカスすることは、主要な多くの組み込みアプリケーションの可能性を無視している。」とも。彼は以下のような既存の単一プロセッサの選択肢を示した。

• RTLINUXのデュアル・カーネル・アプローチ
• RTAI/Adeosのドメイン・アプローチ
• KURT/Libertosの"in-kernel"アプローチ

Paulはこれらのいずれにも満足せずに、4番めの可能性を示した。

単一のOSに2つのCPUがあるという錯覚させる、Xen VMMのようなものである。あなたは、OSは実際には割込みを無効にすることを許可できないと言うが、替わりの方法として、与えられた「CPU」で割込みを無効であるとOSが考えても、下位層のVMMが追跡し、OSがレディになるまで、割込みの伝送を差し控えることができる。勿論マルチスレッドのCPUかSMPシステムにおいては、VMMは必要ではない。

彼は組み込みSMPシステムについての全体のアイデアに関して、「ARMのSMPサポートを見たことで、乗り越えるのはそれほど大変ではないと信じている」と付け加えた。それに対してJon Mastersが答えた。

それらはSMPをリファレンスにして実装しているようだが、多くの人は実際のところ、（明らかに増加する設計の複雑さには価値が見出せない）組み込み設計において、デュアルコア・アプローチには行きたくないのではないか。私は最近確かに、まさしくこの問題に関する長い議論をしている。他の人は賛成しないだろう。私は様々なエンジニアとの会話をもとに記述しているだけである。アイデアは結局面白くなるとは思うが、今はまだそれを進める正しいときではない。人々はまだ今これを望んでいない。

デュアルARMコア・デザインを現在持っているSmartphone製作者と話しなさい。一方でLinuxを走らせ、他方ではGSMとその他のphone関連のためのRTOSを実行している。そして彼らは実際に、設計の複雑さを単一コアに縮小したいと言うだろう。人々と話していると、マルチコア・デザインが確実に良い状況なことは聞いている。しかし一般人はまだ、あなたの方法のリアルタイムに対応するところまでは行かない。確かにそこには、ひとつのOSしかない。恐らく意見を異にするところである。しかし我々は今、全てがマルチコアである状況にはいない。従って一般を納得させることはできない。

私の異なる意見については全てを言ったということで、高解像度画像処理機器を作るいくつかの人々向けのSMP PPC(PowerPC 405ハードウェアコアを２個備えたXilinx Virtex IIpro)カーネルとユーザスペースをハックした話をしよう。それは、パルス信号およびデータ取得に対する非常に正確な（ナノ秒/マイクロ秒精度の）コントロールを含んでいる。我々はまさしくLinuxのこの決定的な応答レベルを明らかにできないため、結局個別コアにジョブを依頼している。あなたのアプローチがハードウェア開発者を納得させることは、ありそうもないだろう。しかし、私は今後、ある時点でそれが魅力的になる場合があると推測している。

まだこの続きがあるのだが、それは次回に。