Linuxカーネルバージョン3.3および3.4​​を初めて知った人

次は、IBM Webサイトからの記事の翻訳です。 それから根本的に新しい何かを学ぶことはまずありません。 この記事は、Linuxの興味深い機能や以前は未知だった機能について読むための出発点として使用するのに適しています。 リンクの一部を斜体で引用しました。一部は元の記事の最後にあります。 説明またはコメントは斜体で記載しています。



Linuxカーネルリリースバージョン3.3および3.4​​には、印象的な改善が含まれています。 ただし、これらのリリースは単なるコア開発ではなく、この開発への道のりの不吉なマイルストーンです。

バージョン3.3のリリースは、Linuxカーネルの最初のリリースであり、そのボリュームは1500万行を超えています（率直にカーブした測定方法を使用した場合でも）。 変数（コードの一貫性のない部分（さまざまなドライバー、プラットフォーム固有のコード、およびさまざまなユーティリティ））を差し引くと、行数は400万をわずかに下回ります。



この時点で不吉なのは、コアの成長速度（2008年からの50％の成長）、およびこの成長がコアに悪影響を与える可能性があるという事実です（パフォーマンスとカーネル機能の両方の面で）。 機会とパフォーマンスは通常「パッチ」では測定されないため、しばらくの間残るカーネルでバグを見つけることができます（たとえば、PCIe ASPMの問題は、ほぼ1年間カーネルにありましたが、バージョン3.3 のwww.pcworldの説明で修正されました）。 com / businesscenter / article / 244277 / new_kernel_patch_slashes_linuxs_power_appetite.htmlおよびパッチlkml.org/lkml/2011/11/10/467 ）



Linuxは21年足らずで10,000行のコードから1500万行以上に成長しました。 さらに、このコードのほとんどはドライバーサブツリーにあり、サイズが大きくなるとカーネルの複雑さが増します。 遅かれ早かれ、この拡張機能はカーネルをよりシンプルにする変更をもたらすはずです。 コードの観点からも、このコードのサポートの観点からも。







図番号1に示すように、2001年に2.4がリリースされて以来、コアは急速に成長しています（2012年の3,377,902行から15,998,651行）。 この期間中、毎年約100万行がカーネルに追加されました。 これは見事な図解であり、すべてのソフトウェア開発者に恐怖を抱かせるはずです。



彼らは、核が成長するにつれて核を支えることに対する彼の懸念について、トーバルズ自身の言葉を引用しています。 カーネルのコアを構成する400万行のコードにより、現在のカーネルソース管理システムの改善が必要になる場合があります。

Androidの統合。

3.3カーネルの最大のニュースは、Google Androidカーネルのメインブランチに含まれることです。 この統合は3.4カーネルでも継続されますが、ユーザー空間でのアンドロイドのロードをサポートするのに十分なアンドロイドのコードがカーネルに含まれるようになりました。 Androidカーネルは、いくつかの機能を備えたLinuxカーネルのフォークです。 これらの機能は、手ごろな電力で厳しく制限されているモバイルデバイスの効率的な操作のために導入されています。 さらに、Androidでは、x86サポートも存在しますが（たとえば、Google TVプロジェクトなど）、ARMアーキテクチャに重点が置かれています。



LinuxのメンテナーとGoogleの間の相互作用の問題により、Androidは数年間個別に開発されました。 2011年から2012年の冬に、Android Mainliningプロジェクトが作成されました。このプロジェクトの目標は、Androidカーネルのドライバーと新機能をメインのLinuxソースツリーに統合することです。 行われた作業はカーネル3.3で一般に公開され、今後のリリースでも継続されます。



Androidは、モバイル環境での競争力を高めるために必要なLinuxにいくつかの改善を加えました。 例には、高速プロセス間通信（Fast IPC）メカニズム、改善されたメモリ管理メカニズム、および大きな連続したメモリ領域を管理する問題の解決策が含まれます。



バインダーは、Androidが標準のIPCメカニズムに応答したドライバーです。 Android開発者は既存のコードを簡単に使用できますが、 バインダーの開発では、以前はアクセスできなかったいくつかのユニークな「トリック」を提供しました（「 資格情報 」をコピーおよび送信せずにメッセージを送信します 。詳細については、 lwn.net / Articles / 466304を参照）。 Androidでは、アプリケーションは通常の方法で終了することはなく、カーネルが完了するまで動作します。 メモリ使用量を最適化するために、 Shrinkerと呼ばれるメカニズムがあります。 アプリケーションは、呼び出されたときに使用するメモリ量を最小化する関数を登録します。 カーネルは、メモリが不足し始めるとこれらの関数を呼び出します。 Androidから移行した別のメカニズムはPmemです。 このメカニズムにより、物理的に連続したメモリを割り当てることができます。 たとえば、カメラが電話で使用される場合、同様の機能が使用されます。 このメカニズムの一部として、ユーザー空間にAPIがあり、これを使用してシステムから連続したメモリを取得できます。 これらのメカニズムに加えて、モバイルデバイスに固有のその他の機能がAndroidから転送されました。



一部のメカニズムはまだカーネルにヒットしていません。 たとえば、 wakelocksは、個々のプログラムがシステムが低電力状態になるのを防ぐことができる電力管理メカニズムです（たとえば、更新が進行中の場合）。 もちろん、これによってAndroidの読み込みが妨げられることはありませんが、バッテリーの高速消費につながる可能性があります。



AndroidとメインのLinuxカーネル開発ブランチとの合併は、Linuxの柔軟性のもう1つの例です。 組み込みシステムやモバイルシステムから世界最大のメインフレームやスーパーコンピューターに至るまで、Linuxはあらゆる場所で定着しています。 また、Linuxは3億台以上のモバイルデバイス上のユニバーサルシステムとして進化を続けています。

vswitchを開く

Linuxは引き続き最も人気のある仮想化プラットフォームです。 Linuxは世界クラスのオペレーティングシステムであるだけでなく、世界クラスのハイパーバイザーでもあります。 カーネルのメインブランチにOpen vSwitchが導入されたことにより、Linuxを仮想化プラットフォームとして使用し、LinuxでIaaSサービスを提供しているユーザーのこのステータスが確認されました。



仮想スイッチは、ハードウェアスイッチのソフトウェア実装にすぎません。 仮想化プラットフォーム（KVMまたはXenで作成された形式）により、マシンの物理リソースへのアクセスを制御するハイパーバイザー上でオペレーティングシステムの複数のコピーを（仮想マシンとして）実行できる場合に備えて、思い出させてください。 仮想スイッチの導入により、ネットワークインフラストラクチャの新しい形式が導入され、この抽象化が拡張されます。 仮想スイッチは、仮想マシンが仮想ネットワークを介して互いに通信するための強力なツールを提供します。 Open vSwitchは仮想スイッチの機能を拡張し、複数のハイパーバイザーの仮想ネットワークを組み合わせることができます。 このようにして、仮想マシンは、仮想ネットワークを介して他のハイパーバイザーにあるマシンと通信できます。



内部では、 Open vSwitchはネットワーク仮想化のための幅広い機能を実装しています。 これらの機能の中には、QoS、vlan'y、フィルタリングとトラフィックの分離、監視と制御のための一連のプロトコル（OpenFlowやNetFlowなど）があります。 Linuxにはすでに仮想スイッチ（Linuxブリッジ）が実装されているという事実にもかかわらず、 Open vSwitchははるかに機能的なソリューションであり、したがって歓迎すべき追加機能です。

ファイルシステムの変更。

リリース3.3では、ユーザーと開発者の両方に関連するいくつかのファイルシステムにいくつかの変更が加えられています。 ユーザーにとっては、これは入出力操作の制御によるext4ボリュームのオンラインサイズ変更です（「EXT4_IOC_RESIZE_FS」フラグを使用したioctl呼び出し）。 「オンライン」とは、システムが動作し続けることを意味します。 さらに、サイズ変更操作全体がカーネルで実行されるようになり、速度が向上しました。



btrfsのバランシングメカニズムが書き直されました 。 現在は、作業の一時停止と再開をサポートしています。 このメカニズムは、たとえば新しいハードディスクの追加など、メタデータ構造を変更するために使用されます。 btrfsの改善はリリース3.4でも継続され、破損したボリュームからデータを回復するためのユーティリティが導入されました（ btrfs-restore ）。 さらに、リリース3.4にいくつかの変更が加えられ、 btrfsのパフォーマンスとエラー処理が改善されました。エラーメッセージの代わりに、これらのエラーのエレガントな処理になりました。 3.4リリースより前では、COWメカニズムにより、 btrfsはLinux仮想メモリマネージャとの互換性が不十分でした（後者は、btrfsで必要以上に長く必要でなくなったページをキャッシュする傾向がありました）。 この欠陥を改善するために改良が行われました。 （ juick.com/thegreatz/1982110#5で修正 ）



RAIDの実装も変更されました。 現在、RAIDのソフトウェア実装はホットスワップをサポートしています。あるボリュームのデータを別のボリュームに転送し、最初のボリュームを後でデータを失うことなくアレイから削除できます。 この機能は、使い慣れたmdadmによって制御されます。

最後に、リリース3.4では、 QNX4ファイルシステムのサポートが追加されました（これまでは読み取り専用モードで）。



開発者は、これらのエラーから回復するクライアントの能力を確認するために、ネットワークファイルシステム（ NFS ）操作にエラーを導入することができました（メカニズムはsysfsを介して機能します）。 brtfs開発者向けに、ファイルシステム整合性チェックユーティリティが追加されました。これは、無効な書き込み要求を検出するために使用でき、問題をより迅速に修正するのに役立ちます。

ネットワークの改善。

また、リリース3.3では、いくつかの高度な変更が行われました。



低遅延環境（スーパーコンピューターコンピューティングなど）の場合、SCSI RDMAプロトコル経由でデバイスへのアクセスを提供する機能が導入されました（ ru.wikipedia.org/wiki/InfiniBandで簡単に読むことができます ）。 SCSI RDMAは、ブロックデバイスのトランスポートとしてRDMAを使用できるようにするプロトコルです。 RDMAはInfiniBandでサポートされており、スーパーコンピューターコンピューティングではかなり一般的です。



RED（ランダム早期検出 ）パッケージスケジューラが変更されました。 作業のアルゴリズムは、Sally Floyd（Sally Floyd）、Ramakrishna Gammadi（Ramakrishna Gummadi）、およびScott Shenker（Scott Shenker）の提案に従って変更されました。 新しいスケジューラは、 ARED （Adaptive RED、一般にアダプティブとして翻訳されます）と呼ばれます。 REDは、統計的な確率に基づいて、キューとドロップされたパケットの平均サイズを追跡します。 空のキューでは、すべてのパケットが受け入れられます。 キューがしきい値を超えていっぱいになると、ほとんどすべてのパケットが破棄されます。 AREDは、平均キュー長の観察に基づいて、REDをより積極的にするか、積極的にしないかをケースバイケースで決定します。 AREDの詳細については、icir.org / floyd / papers / adaptiveRed.pdfの資料をご覧ください 。



また、リリース3.3では、古いボンディングドライバーに代わる新しい実装が追加されました。 複数の物理インターフェイスを1つの仮想インターフェイスにグループ化することにより、信頼性と帯域幅が（たとえば、802.1AXプロトコルに準拠した）インターフェイスを作成できます。 現在、新しいメカニズムの2つの動作モードがサポートされています。ラウンドロビンルールまたはアクティブバックアップルールによるパケットの単純な配布です。 最初の場合、パケットは各物理インターフェイスから順番に送信されます。 2番目の場合、データは1つの物理インターフェースを介して送信され、「ドロップ」されるとスペアを介して送信されます。



行われた多数の変更の中で、 cgroups実装への興味深い追加も強調できます。TCPのバッファ制限の実装が追加されています。 cgroupはさまざまな方法で使用されます。 含む-仮想マシンのリソースを制限します。 この変更後、システムメモリの使用をさらに微調整できるようになり、システム全体のより詳細な制御が可能になりました。

その他の興味深い変更

カーネルリリース3.3には、ファイルシステムまたはネットワークに関連しない変更も含まれています。 新しいアーキテクチャのサポートが追加されました。TexasInstruments C6xプロセスをサポートするために、プロジェクトコードがカーネルのメインブランチに追加されました。 C6xは、1つ以上のコアを備えたVLIWアーキテクチャプロセッサです。 これらのプロセッサは、SMPやキャッシュの一貫性などの機能をサポートしていません。 また、メモリ管理ユニット（MMU）もありません。 これらの欠点にもかかわらず、C6xシリーズプロセッサには、さまざまな周辺機器とチップ上で直接作成された追加ブロックがあります（たとえば、高速フーリエ変換用）。

リリース3.4には、Nvidia Keplerや最新のAMD RadeonおよびTrinityなどの最新GPUのサポートが含まれています。



ARMアーキテクチャは、LPAE拡張をサポートするようになりました（最大1TBのメモリを処理するためのPAE。詳細については、例えばwww.linux-arm.info/index.php/130-linux-support-for-arm-lpaeのPDFを参照してください）。 さらに、Nvidia（Tegra 3）のシングルチップシステムのサポートが含まれています。 これらの変更により、ARMプロセッサは低電力サーバーセグメントのIntelプロセッサと競合できます。 AMD IOMMUの実装に多くの変更が加えられ、メモリデバイスへのアクセスに関して、サイズ変更可能なメモリページの管理とセキュリティが改善されました。 仮想I / O機能により、KVMのデバイスを仮想マシンに提供する機能が拡張され、さらに、S390アーキテクチャは最大64 TBのRAMをサポートするように改良されました（以前のバージョンでは1 TBでした）



パフォーマンスモニタリングユニットがKVMの仮想インターフェイスを受け取りました。 したがって、ゲストOSはプラットフォームのパフォーマンスを追跡できるようになりました。 この監視の一部として、「実行された命令（廃止された命令）の数、キャッシュでのヒットとミス、および遷移の予測の成功などのメトリックが利用可能です。 別の有用な革新は、「安全なリセット」機能です。 この機能により、リクエスト内のセクターを空きとしてマークするだけでなく、完全に削除することができます。

さまざまなI / Oドライバー（blk、net、balloon、console）がACPIおよびS4スリープ状態をサポートするようになりました。つまり、Xen上のゲストVMを休止状態にできるようになりました。



複雑なメモリ破損の問題をデバッグするために、新しいCONFIG_DEBUG_PAGEALLOC構成オプションが追加されました。 オンにすると、未割り当てページへのプロセッサのアクセスが監視されます。 このオプションを有効にすると、当然パフォーマンスが低下します。

未来への展望。

Linuxは進化を続けており、リリース3.4はすでにリリースされていますが、リリース候補3.5は2012年8月にリリースの準備がほぼ整っています。

次のリリースでは、多くの新しいことも待っています：btrfsではライトバックメカニズムが改善され、ext4ではデータ操作を決定するためにチェックサムを保存する機能が追加されました。 LinuxはまもなくSCSI over FireWireまたはSCSI over USBを使用したデバイスへのアクセスをサポートするかもしれません。 また、ユーザー空間での調査サポートと、受信したデータを分析するためのSystemTapの使用を約束します。 将来的には、コアが開発されるにつれて、さらに多くの興味深いことがあります。