SourceForge.JP: Open Source Software

我々は、2.6.9-rc3-mmカーネル・シリーズにこれをポーティング中である。一般からフィード・バックを貰い、同様のカーネル・エンハンスメント作業を、他と共有させたいと考えて、この段階で仕事を示すことにした。

Sven-Thorsten Dietrichからの、[ANNOUNCE] Linux 2.6 Real Time Kernelと題したLKMLへの10月9日のポストである。

最近では、2.6のKernelプリエンプションを実装したIngo Molnarが、「Voluntary」プリエンプションPatchを公開しているほか、LKMLではカーネルのRealTime化や割込み処理のレイテンシ（遅延）縮小に関する議論が増えてきている。

Sven-Thorsten Dietrichのアナウンスは以下のように続く。

最初に

これらのRTエンハンスメントは次のように、いくつかの機能を集積したものである。

• Ingo Molnarの「Voluntary」プリエンプション
• Scott Wood と Ingo Molnarによる、IRQスレッドpatch
• Ingo MolnarによるBKL mutex patch (MV extension付)
• Germany's Universitaet der Bundeswehr, MunichからのPMutex
• mutexes付spinlockを置き換えるMontaVistaのmutexアブストラクト・レイヤ

なぜLinuxでのRTサポートなのか

我々の目的は、Linux 2.6カーネルを高機能マルチメディア・アプリケーションと、非常に速く、タスク・レベルで信頼できる制御機能を要求するアプリケーションに対して使用可能にすることである。

AV企業は、Linuxの上でHDTVに関連する技術を構築している。また、デスクトップ・システムはますます同様のアプリケーションに使用される。

携帯電話、PDAおよびMP3プレーヤは、数多くのスレッドを要求する高度に統合されたデバイスへと、互いに近寄ってきている。これらのスレッドは多くの通信プロトコル(IP、Bluetooth、802.11、GSM(CDMA)などをサポートする。特にセルラー・ベースのプロトコルは、デッドラインに非常に敏感な操作が、確実に作動することを要求する。

GPSの処理は、例えば、厳しいリアルタイムタスクと保証されたKHzレベルの周波数割込み処理を要求する。セント・ヘレンズ火山の内部のように、たどり着けないか危険な場所のLinuxベースのリモート・コントロールGPSステーションは、IPによって実際のデータを流す。

さらにLinuxはレーダ処理、ファクトリー・オートメーション・システム、「ループ内の」プロセス・コントロール・システム、医療、および計測システム、自動運転制御システムといった、従来のリアルタイム制御環境でも、ますます利用されている。これらのシステムは多くの場合、数十から数百マイクロ秒のレンジに対する、タスク・レベルでのレスポンス要求を持っている。それは現在の2.6 Linux技術では達成可能ではない、保証されたタスク・レスポンス・レベルである。

他の先行作業

Micro-Kernelによるいくつかの解決策がある。それらは必要な性能を達成することができるが、これらの手段には2つの一般的な懸念事項がある。

1. システム全体の複雑さをを含めて構築する方法と、アプリケーション・デザイン・レベル複雑さに対応する、2つの別なカーネル環境がある。
2. 法的論議

上記に挙げた以前からのカーネル・エンハンスメントに従って、我々の仕事は、既存のアプリケーションとドライバに対して、透過であることを目指している。

最新のPatchは以下にある。

ftp://source.mvista.com/pub/realtime/

Ingo Molnar

素晴らしい！(cool!)

Ingo Molnarが答えた。

基本的には、最も大きな問題は技術自体ではなく、それのLinuxへ適切なインテグレーションである。2.4のRTパッチ(TimeSysとあなたのもの)からわかる様に、単に完全にプリエンプティブなカーネルへの道を歩くことは有益ではない。なぜなら、それは結局Linuxツリーとして維持できない分岐を作り出すほどの、大規模で深いパッチを多数生成することになるからである。

別のアプローチは、私が現在、「Voluntary」プリエンプションのPatchで行っているものである。多くの特別な機能を加えることを実際にせずに、レイテンシ目的のためにジェネリック・カーネルを改善することである。今ちょうどここに、-mmツリーで起こっていることがある。

• 一般的なirqサブシステム： irqスレッドは単純で、200ライン程度までである。アーキテクチャ依存のコードは、これに追加することにする。3つの異なる実装を提供しても意味がない。1つを取り、それをうまく生かすことを支援すべきである。

• preemptible BKL： mutexへのスピンロックの安全で遅い変換を許可するという、-mmの新しいデバッグ・インフラがこれに関連づけられる。BKL(Big Kernel Lock)の場合には、この変換が永久であると期待している。ほとんどの他のスピンロックについては、それはオプションだろう。しかし、デバッギング・コードは今までどおり使用することができる。

• 様々なFIXとレイテンシの改善： 確実に実行することができるただ一つのコードがユーザスペース・コードで、カーネル・スペースでRTアプリケーションをたたく瞬間が高いレイテンシに晒される場合、mutexベースのカーネルはほとんど役に立たない。

2、3の提案がある。どのようにしてこのインテグレーションをスピードアップするか。-mmツリーに、これらの素材を再提供してはどうだろうか。また、私がパッチで（まだ）見ていない部分は、より難しい素材となっているのではないだろうか。

• CPUごとのデータ構造(get_cpu_var())の取り扱い
• RCUとsoftirqのデータ構造
• IRQフラグの取り扱い

これらは基本的に、UPへの影響がSMPに対するのと同じ程度の正確さが必要になる問題である。これらがなくては、カーネルはまだ「完全にプリエンプティブな」カーネルではない。これらはインフラストラクチャー変更をまた必要とする。従って、spinlock -> mutex変換のような追加作業も必要となる。

その結果恐らく、mutex Patchは「ついに」上流に行くことができるものとなるだろう。それはカーネルを「完全にプリエンプティブ」にする「最終ステップ」となるものである。

この後、様々な技術的な問題が議論されたのだが、この続きは次回へ。

（2005年4月2日 ミススペルを訂正）