Linux カーネル 3.3 と 3.4 の紹介

最新の Linux カーネルについて、Google Android、Open vSwitch、ネットワーク、その他に関する機能を概説する

M. Tim Jones
配信 2012年 7月 19日

Tim とつながるには

Tim は developerWorks で人気の高いお馴染みの著者の 1 人です。Tim が書いたすべての developerWorks 記事を閲覧してみてください。また、developerWorks コミュニティーでは、Tim のプロフィールを調べることや、彼やその他の著者、そして他の開発者とつながることができます。

Linux カーネルの 3.3 リリースと 3.4 リリースには素晴らしい機能セットが含まれていますが、これらのリリースはどこか不安なマイルストーンでもあります。3.3 リリースはコードが 1500 万行を超える初の Linux リリースです (ただし正直なところ、この行数の計測には欠陥のある手法が使われています)。Linux カーネルのうち、可変部分 (ドライバー、アーキテクチャーに依存するコード、さまざまなツールなど) を除けば、その行数は 400 万行を下回るところまで減りますが、これだけでも巨大です。

このマイルストーンに関して不安に感じられる部分は、カーネル・サイズの増大の速さ (2008年から 50% の増加) と、この増大が Linux カーネルの効率 (処理能力とパフォーマンスの両方) に悪影響を及ぼし始めるのではないか、という 2 点です。処理能力とパフォーマンスは必ずしもパッチごとに測定されるわけではないため、リリースされたカーネルの中にはバグが容易に入り込み、しばらくの間残っている可能性があります (例えば、PCI Express (PCIe) の Active State Power Management による電源管理の問題は 3.3 リリースで修正されていますが、カーネルの中に 1 年間存在していました)。

Linux カーネルのバージョン番号の付け方

カーネルのバージョン番号は、3 つに区切られた数字を用いる方式が採られており、カーネルのバージョンにメジャー・リビジョンとマイナー・リビジョンが続く構成になっています (例えば 3.3.4 など)。リリース候補のカーネルには rc# というサフィックスが付けられ、このサフィックスには特定の候補を表す数字が含まれています (例えば最新候補は 3.5rc1 です)。

Linux が誕生してからまもなく 21 年になろうとしていますが、当初 1 万行を超える程度だった Linux のコードは今や 1500 万行を超えるほどにまで増大しました。これらのコードの大半はドライバーのサブツリーの中にありますが、カーネルはコードのサイズが大きくなるとともに複雑さも増しています。このコードが増大した結果として、いつかそう遠くない日に、複雑さを解消して保守性を高めるための変更がカーネルに加えられる可能性があります。

図 1 に示すように、Linux カーネルのサイズは 2001年の 2.4 リリース以降、急速に増大しました (2001年には 3,377,902 行であったものが、2012 年には 14,998,651 行になっています)。この間、毎年約 100 万行もの新しいコードがカーネルに追加されており、この驚くべき数字にソフトウェア開発者は不安を感じるはずです。

図 1. 2.2 リリース (2001年) から 3.3 リリース (2012年) に至るまでのカーネルのサイズの変化

2.2 リリース (2001年) から 3.3 リリース (2012年) に至るまでのカーネルのサイズの変化を示すグラフ

クリックして大きなイメージを見る

このカーネルの巨大化に関しては、Torvalds 氏自身も今後の保守について懸念を示していると言われています。カーネルのみで約 400 万行ものコードになることから、現在のカーネル管理手法を強化する必要があるかもしれません。

Android との統合

Linux カーネル 3.3 における最大のニュースは、メインライン・カーネルへの Google Android の統合が開始されたことです。この統合は Linux カーネル 3.4 でも継続されますが、3.3 リリースの時点でも既に Android ユーザー空間を起動するのに十分な Android フォークがメインラインに統合されています (図 2 を参照)。Android カーネルは Linux カーネルからフォークしたものであり、(使用できる電力に制限のあるモバイル機器の要求に合わせて) 電源を操作する機能やリソースを効率良く使用するための機能がいくつも追加されています。重点が置かれているのは ARM アーキテクチャーですが、(Google TV プロジェクトなどで使用される) x86 もサポートされています。

図 2. Oracle VM VirtualBox 上の Android x86 で Android ユーザー空間を起動する

Oracle VM VirtualBox 上の Android x86 で Android ユーザー空間を起動する様子を示したスクリーン・キャプチャー

クリックして大きなイメージを見る

Linux のメンテナーと Google との間での協力の問題から、この 2、3 年の間、Android の開発は Linux とは無関係に行われてきました。しかし、2011年から 2012年にかけての冬に、Android のドライバーと機能を Linux のメインライン・カーネルに統合することを目標にした Android Mainlining Project が発足しました。このプロジェクトによる統合作業の成果は 3.3 リリースから反映されていますが、3.5 リリースではさらに統合が進むはずです。

Android を作成する際にはベースとなる Linux に対して、モバイル環境で競争力を持つ上で必要な機能強化が行われました。その一例としては、高速なプロセス間通信 (IPC) の追加、アプリケーションのメモリー管理の改善、そして連続する大規模な物理メモリーの管理問題に対するソリューションの追加が挙げられます。

1 つ目の機能強化である IPC を実現するために、Android では Binder と呼ばれるドライバーを導入しました。Android 開発者達は既存の方式を再利用することも簡単にできましたが、Binder を導入することで、それまでにはなかったユニークな機能を追加しました (例えばコピーなしでメッセージを渡す機能やクレデンシャルを渡す機能など)。そして 2 つ目の機能強化として、Android 内ではアプリケーションが終了されることはなく、カーネルがそのアプリケーションを削除するまで実行が継続されるため、メモリーの空き容量が少なくなった場合にメモリー使用率を改善するために、Shrinker というメカニズムが導入されました。このメカニズムは、あらかじめアプリケーションはメモリーの使用量を最小限にするために呼び出す関数を登録しておき、メモリーの空き容量が少なくなってくると、カーネルはこれらの関数を呼び出すというものです。Android によって追加されたもう 1 つの機能が、物理的に連続した大容量のバッファーが必要な場合に (例えば、カメラ機能などの場合に) そうしたバッファーの割り当てを行う機能を提供する Pmemです。Pmem は、この種のメモリー割り当てを行うためのユーザー空間ドライバーをエクスポートします。他にも機能が導入されていますが、それらはいずれもモバイル分野に特有の機能です。

まだカーネルに採用されていない機能もあります。例えば wakelock という電源管理機能を利用すると、コンポーネントは (例えば、更新が行われている最中などに) システムが低電力状態に入るのを防ぐことができます。wakelock がなくても Android システムを起動できないわけではありませんが、バッテリーの消耗は早くなります。

Android が再び Linux カーネルにマージされることは、(組み込みシステムやモバイル機器から最大のメインフレームやスーパーコンピューターに至るまで使用できる) Linux カーネルの柔軟性を示す好例でもあります。3 億台を超える Android 機器が使用されている現在、Linux は汎用のプラットフォームとして進化を続けています。

Open vSwitch

Linux は、仮想化の際に選択されるプラットフォームとしての地位を保っており、世界クラスのオペレーティング・システムであることに加え、世界クラスのハイパーバイザーでもあります。メインライン・カーネルに Open vSwitch を含めたことにより、そのまま仮想化や IaaS (Infrastructure as a Service) に利用できるようにしたことで、Linux は世界クラスのハイパーバイザーとしての地位を一層強固なものにしています。

仮想スイッチは、物理スイッチをソフトウェアで実現したものにすぎません。ここで (KVM (Kernel-based Virtual Machine) や Xen によって実装される) プラットフォーム仮想化を行うことにより、物理プラットフォームを多様な仮想プラットフォームへと変えるハイパーバイザー上で、複数のオペレーティング・システムのインスタンスを (VM として) 実行できるようになるということを思い出してください。仮想スイッチは、このプラットフォーム仮想化による抽象化を拡張し、ネットワーク・インフラストラクチャーに仮想化の形態を導入することで、VM 同士が仮想ネットワークを介して通信する効率的な手段を提供します。Open vSwitch はこの抽象化を複数の仮想ホストにわたって拡張することで、1 つの物理ホスト上の複数の VM が別の物理ホスト上の複数の VM とトランスペアレントに通信できるようにします。

Open vSwitch には仮想ネットワークを実現するための豊富な機能が含まれています。例えば、QoS (サービス品質)、仮想 LAN、トラフィックのフィルタリングと分離、監視と制御のためのさまざまなプロトコル (OpenFlow や NetFlow など) などをサポートしています。Linux には以前から仮想スイッチの実装がありました (Linux Bridge と呼ばれます) が、Open vSwitch の方が (マルチホスト管理ができるなど) はるかに機能の豊富なソリューションであるため、Open vSwitch が追加されたことは歓迎すべきことです。詳細については「参考文献」を参照してください。

ファイルシステムに関する変更

Linux カーネル 3.3 では、ユーザーおよび開発者の両方にとってのファイルシステムに関する変更が、いくつものファイルシステムにわたって行われています。ユーザーにとっての変更としては、I/O 制御によって ext4 (第 4 世代拡張ファイルシステム) を「オンラインで」リサイズできるようになりました (この場合の「オンラインで」というのは、システムを動作させたまま、という意味です)。これはつまり、全体のリサイズがカーネル内で実行されるということであり、その結果として従来よりもはるかに高速なリサイズが可能になります。

Btrfs (B-tree file system) に関しては、バランス動作 (新しいドライブが追加された場合など、基礎となるメタデータの構造を変更する場合に使用されます) が作成し直され、一時停止と再開がサポートされるようになりました。Btrfs の機能強化は 3.4 リリースでも継続され、新しいデータ復元ツール (btrfs-restore) が追加されています。このツールを使用すると破損した btrfs ファイルシステムからファイルを抽出することができます。また 3.4 リリースでは Btrfs のパフォーマンスが何点か改善され、エラー処理も改善されています (例えば、カーネル・パニックがなくなり、代わりにグレースフルなエラー管理が行われるようになりました)。Btrfs ではコピー・オン・ライト・メカニズムが採用されていることから、3.4 リリースよりも前のリリースでは VM 内のファイルシステムとしてはうまく動作しませんでした。こうした問題点を最小限にするために、調整が行われてきました。

ソフトウェア RAID (Redundant Array Of Independent Disks) も更新され、ホット・リプレースがサポートされています。この機能により、(置き換え可能のマーキング mdadm を付けた) あるボリュームのデータを別のボリュームにマイグレートした後に元のデータを削除することができます。最後に、3.4 では QNX4 ファイルシステムに対して読み取り専用機能が追加されています。

開発者にとっての変更としては、Network File System にエラーを注入し、クライアントが (sysfs によって) エラーから回復できるかどうかをテストすることができるようになりました。Btrfs 開発者にとっては、完全性をチェックするための新しいユーティリティーが追加されました。このユーティリティーは、無効な書き込み要求を明らかにすることができるため、より迅速なバグ解決のために役立てられるはずです。

ネットワーク機能の強化

Linux には最先端のネットワーク機能が用意されており、Linux カーネル 3.3 で、いくつかの機能強化が行われています。

低遅延のインフラストラクチャー (ハイパフォーマンス・コンピューティングなど) 用には、SRP (SCSI RDMA (Remote Direct Memory Access) Protocol) ターゲット用ドライバーが実装されました。RDMA プロトコルをブロック・ストレージ・デバイス用のトランスポートとして使用できるようにするのが SRP です。この機能追加により、Linux は SRP を使用してブロック・デバイスを公開できるようになりました。リモート・イニシエーターは、ブロック I/O 処理を行うための接続に SRP を使用することができます。RDMA は InfiniBand でサポートされており、ハイパフォーマンス・クラスターではごく一般的に使用されています。

RED (Random Early Detection: ランダム初期検知) パケット・スケジューラーは、Sally Floyd 氏、Ramakrishna Gummadi 氏、Scott Shenker 氏が考案した ARED (Adaptive RED: 適応ランダム初期検知) という新しいアルゴリズムを使用して変更されました。RED は実証済みの効率的なパケット・スケジューラー・アルゴリズムです (このアルゴリズムでは、キューの空き容量に応じて、着信パケットをバッファリングできないパケットとして破棄するかどうかを決定します) が、ネットワーク内の輻輳の影響を受けやすいことがわかっています。RED は、キューの空き容量を基にパケット破棄の確率を決定するので、キューが空の場合やほとんど空の場合にはすべてのパケットが受け付けられますが、キューが一杯になると、すべてのパケットが破棄されてしまいます。これに対し、ARED は、パケット破棄の動作がアルゴリズムによってどの程度実行されたかを測定し、それによってパケット破棄の確率を動的に変更します。このアルゴリズムの詳細については、「参考文献」のリンクに挙げた ARED についての論文を読んでください。

かつてのカーネル・ボンディング・ドライバーに代わり、新たにチーミング・ネットワーク・デバイスが追加されました。チーミング・デバイスを利用すると、(リンク・アグリゲーションおよび 802.1AX によって定義されるように) 複数の物理イーサネット・デバイスから使用可能な帯域幅を集約して仮想インターフェースを作成することができます。このデバイスを使用することで、(複数の物理デバイスを集約して) ネットワークのパフォーマンスを高めたり、(トランスペアレントなフェイルオーバーを行うことで) 冗長性を持たせたりすることができます。現在は 2 つのモードがサポートされており、単純に物理ポート全体にわたってラウンドロビン方式でトラフィックを割り当てることも、アクティブなバックアップとして 1 つのポートを定義し、メインのネットワーク接続が失われた場合にすべてのトラフィックをそこにルーティングすることもできます。

ネットワークに関する数多くの機能強化の中で、もう 1 つの興味深い変更が、コントロール・グループ (つまり cgroup) に対して TCP バッファーの制限を追加したことです。cgroup はさまざまな目的に使用されています (例えば、VM のリソースを分離するためなど)。今回の変更により、ユーザー空間メモリーと (TCP バッファーに使用されるような) カーネル・メモリーの両方を 1 つの cgroup 内で追跡できるようになるため、システム・リソースをより適切に管理できるようになります。

その他の興味深い変更

Linux 3.3 には、ファイルシステムにもネットワークにも関係のない変更も導入されています。新しいアーキテクチャーに関して言えば、Texas Instruments の C6x プロセッサーが (別のプロジェクトとしてではなく) 直接サポートされるようになりました。C6x は VLIW (Very Long Instruction Word) ベースのシングルコアまたはマルチコアの DSP (Digital Signal Processor) ですが、対称型マルチプロセッシングやキャッシュ・コヒーレンシーのような最近の機能はなく、またMMU (Memory Management Unit) もありません。こうしたアーキテクチャー上の不足はあるものの、C6x シリーズは高性能であり、豊富なペリフェラルやオンチップ・アクセラレーター (セキュリティー用、高速フーリエ変換用、その他) が揃っています。3.4 リリースは、Nvidia の Kepler や AMD の最新 Radeon リリースや Trinity リリースなど、最新の GPU プロセッサーをサポートしています。

ARM アーキテクチャー・サブツリーは今や大規模な物理アドレス拡張を使用し、Nvidia Tegra 3 SoC のサポートを導入しています。これは低消費電力サーバーの分野で ARM が Intel に挑戦する中で、理想的なことです。また 3.3 リリースでは AMD の I/O MMU 実装に対する改善がいくつかなされています。これにより、多様なページ・サイズを扱う場合の管理が改善され、デバイスのセキュリティー (デバイスのグループ化や分離など) も強化されています。さらに、VFIO (Virtual Function I/O) では、デバイスを KVMのゲストにマッピングする、KVM の機能を強化しました。最後に、S390 アーキテクチャーが更新され、(たった 4TB 未満という従来の制限を超え) 最大 64TB の RAM にアクセスできるようになりました。

KVM では PMU (Performance Monitoring Unit) が仮想化され、ゲストは自らの仮想プラットフォームの PMU にアクセスできるようになりました。その結果、リタイアされた命令によるイベント、キャッシュ参照とキャッシュ・ミスによるイベント、実行された分岐命令と失敗した分岐命令によるイベントなど、有用なパフォーマンス・イベントを各ゲストに公開することができます。仮想化に関するもう 1 つの便利な機能として、Xen に対してセキュアな破棄がサポートされるようになりました。「セキュアな破棄」というのは、該当のセクターを単純に空のセクターとしてマーキングするのではなく、永久に削除することを意味します。最後に、さまざまな仮想 I/O ドライバー (blk、net、ballon、console など) が ACPI (Advanced Configuration and Power Interface) S4 スリープ状態をサポートするようになりました。つまりゲスト VM が Xen 上でハイバネーション状態になることができます。

デバッグが面倒なメモリー破壊の問題に関しては、CONFIG_DEBUG_PAGEALLOC という新しい構成項目が追加されました。この変更により、割り当てられていないページに CPU がアクセスすることによるパフォーマンス低下がないかどうかをチェックすることができます。

今後の展望

Linux は前進を続けています。3.4 リリースが入手可能となっており、3.5 リリース候補版がまもなく 2012年 8月頃にリリースされる見込みです。Linux 3.5 にはいくつかの新機能や興味深い機能が含まれています。

Btrfs は機能強化が続けられており、今回はファイルシステム内でのライトバック処理が最適化されています。Linux 標準のファイルシステム (ext4) も機能強化され、メタデータにチェックサムを追加できるため、データの改ざんを検出しやすくなります。Linux はまもなく SCSI over FireWire または UASP (USB Attached SCSI Protocol) をサポートするかもしれません。最後に、(SystemTap と組み合わせてユーザー空間のプログラムの動作を分析するための) ユーザー空間プローブがサポートされる見込みです。8 月のリリースに向けてリリース候補が進化するにつれ、さらに多くの変更が期待されています。

ダウンロード可能なリソース

このコンテンツのPDF

目次