(原文はこちら)

「コア カーネル」とは、カーネル全体に影響を与え、かつ特定のサブシステムに密接に結びついていないコードです。Linux カーネルのコアはきわめて小さく、最近は非常に安定しています。CPU スケジューラは徐々に変化していますが、コアのメモリ管理コードにはほとんど根本的な変化がありません。一方、リアル タイム、非同期 I/O、高速ブートなどの多くの領域には、依然として関心が寄せられています。

内容

1. リアルタイム プリエンプション
2. デッドライン スケジューリング
3. メモリ フラグメンテーション回避
4. ヒュージ ページ (Huge Page)
5. syslet と threadlet
6. Big Kernel Lock
7. 高速ブート

リアルタイム プリエンプション

リアルタイム プリエンプション パッチ セットは、決定論的な応答時間を Linux ストック カーネルで提供しようとします。これを実現するには、あらゆるものをプリエンプション可能にします。あらゆるものとは、現行のカーネルでプリエンプション不可能なコード (スピンロックで保護されたクリティカル セクションや割り込みハンドラ) などです。

予報: リアルタイム プリエンプション パッチ セットの多くが、すでにメインラインに入っています。しかし最も問題となる変更はツリーの外に残っており、特にプリエンプション可能なスピンロックは、まだメインラインに入っていません。リアルタイム開発者は残っている処理の多くを来年中にマージしようとしています (ここ数年ずっとそうでしたが)。
とはいえ、リアルタイム開発者が最近このプロジェクトに戻ってきたため、そろそろ進展があるでしょう。2.6.30 でのスレッド割り込みハンドラ インフラストラクチャのマージは、その意味で重要な一歩でした。

詳細情報: このパッチ セットの進化については、以下の記事でも触れています。

• Approaches to realtime Linux
• Realtime preemption, part 2
• Realtime preemption and read-copy-update
• The beginning of the realtime preemption debate
• Clockevents and dyntick
• What's in the realtime tree (October, 2007)
• Moving interrupts to threads (October, 2008)
• The return of the realtime preemption tree (February, 2009)
• The realtime preemption endgame (August, 2009)
• The realtime preemption minisummit (September, 2009) 

デッドライン スケジューリング

古典的な Unix スケジューリングはプライオリティベースであり、リアルタイム スケジューリングも同様です。しかしプライオリティベース スケジューリングは、リアルタイム タスクに適さない場合もあります。リアルタイム タスクとは、一般的に、与えられたデッドラインで終了する処理量で表されます。デッドライン スケジューラーには、「デッドライン」、「最悪実行時間 (WCET)」、「タスクの実行周期」という期間に関する課題があります。この課題を解決できれば、デッドライン スケジューラーは時間通りに処理を終了することを保証でき、システムの能力を超えるタスクを拒否できます。

予報: Linux には高度なデッドライン スケジューラーが提供されています。しかしプライオリティの逆転問題など、解決されるべき多くの課題も残っています。まだ少し時間はかかりますが、2010 年中には完成するでしょう。

詳細情報:

• Deadline scheduling for Linux (October, 2009)

メモリ フラグメンテーション回避

Linux 仮想メモリ システムは、時が経つに連れて物理メモリのフラグメンテーションが進む傾向があります。このフラグメンテーションは通常は問題ありませんが、物理的に連続した大きなメモリ領域が必要な場合には、問題になることがあります。メモリが過度に断片化されていると、複数ページ アロケーションが失敗し、システムの機能が低下する可能性があります。

このフラグメンテーションの問題を解決するための開発も行われています。最も顕著なものが次の 2 つです。

• Lumpy reclaim: 物理的に連続したページを強制的に回収利用する。
• メモリ アロケーションのグルーピング: 移動可能なメモリと移動不可能なメモリを別々に保持できるようにする。

どちらのテクノロジを使用しても、カーネルは連続した複数ページを容易にアロケートできるようになります。また、メモリのホットプラグにはグルーピング パッチが有効です。メモリのホットプラグは仮想化ソリューションで使える機能です。

予報: 基本的フラグメンテーション回避パッチ (ZONE_MOVEABLE メモリ ゾーン) と lumpy reclaim は2.6.23 でマージされました。現行のフラグメンテーションに対する回避機能も今後のカーネルでマージされるでしょう。

詳細情報:

• Fragmentation avoidance (November, 2005)
• Avoiding - and fixing - memory fragmentation (November, 2006)
• Short topics in memory management (February, 2007)
• Memory compaction (January, 2010)

ヒュージ ページ (Huge Page)

Linux は、ほとんどのアーキテクチャで 4096 バイトのメモリ ページを処理します。しかし現在では、多くのプロセッサーがもっと大きなページを処理できますし、「ヒュージ ページ」を使用することで、パフォーマンス的に莫大なメリットが得られる場合もあります。 

予報: これまで Linux は基本的なヒュージ ページ サポートを行ってきましたが、これを使用するには、アプリケーション開発者による特殊な手段が必要です。ヒュージ ページが利用可能で、かつカーネルがその使用を認めたときには、アプリケーションが単純にこれらのページを使用できるような「トランスペアレント ヒュージ ページ」のサポートが重要なはずです。トランスペアレント ヒュージ ページ のパッチ セットが出回っていますが、まだパフォーマンスの問題が残っていますし、メモリ管理コードのマージは常に遅れています。このため、この機能がメインラインに入る正確な時期は予想できません。

詳細情報:

• Transparent huge pages (October, 2009)
• Huge pages part 1 (February, 2010) 

syslet と threadlet

「syslet」とは、カーネル内にある小さなプログラムを実行する手段です。syslet は、合間にユーザー スペースに戻ることなく非同期でシステム コールを実行する方法です。「threadlet」は、同様のメカニズムでユーザー スペースの非同期コードを実行します。どちらの場合も、対象のコードは、ブロックしなければ同期的に実行します。何かを待たなければいけない場合、カーネルは新しいスレッドを作成 (または既存のスペア スレッドを再利用) し、そのスレッドでユーザー スペースの実行を継続します。

このパッチの最初の動機は、現在の AIO アプローチの重いメンテナンス オーバーヘッドなしに、非同期 I/O インプリメンテーションを完了できるようにすることでした。syslet と threadlet はどのようなシステム コールも非同期で実行できますが、それよりさらに広い用途があります。

予報: このコードにはトリッキーなインプリメンテーションの問題があり、またこの新機能に関するユーザーからのプレッシャーがないため、停滞しています。復帰はあるでしょうが、その時期の予測は困難です。

詳細情報:

• Fibrils and asynchronous system calls (January, 2007)
• Alternatives to fibrils (Syslets, February, 2007)
• Threadlets (February, 2007)
• Realtime and syslets (September, 2007)
• Simpler syslets (December, 2007)
• A new approach to asynchronous I/O (January, 2009)
   

Big Kernel Lock

Big Kernel Lock (BKL) は、並行処理を最小化し、基本的な SMP の機能性を実現する方法として、2.0 カーネルで導入されました。しかし、これがスケーラビリティのネックとなっているため、カーネル開発者は BKL をカーネルから取り外すために格闘してきました。最近はますますその緊急性が増し、BKL 除去作業により多くの時間が割かれています。

予報: リアルタイム プリエンプション開発者は、リアルタイム コードをより多くメインラインに入れるプロセスの一環として、BKL を除去することになりました。2.6.33 開発サイクルでは、reiserfs ファイルシステムから BKL を削除するラージ パッチ セットが追加されました。他の多くの呼び出しも削除されています。BKL を完全に取り除くことはできないかもしれませんが、まずは一般的なコード パスが BKL を使用しなくなることを目指しています。

詳細情報:

• The Big Kernel Lock lives on (May, 2004)
• The Big Kernel Lock strikes again (May, 2008)
• Kill BKL Vol. 2 (May, 2008)
• The realtime preemption mini-summit (September, 2009)

高速ブート