仮想化技術分析: 動的アドレス変換

仮想化はメインフレームでは成熟した技術ですが、最近でもこの技術に関する議論が多く聞かれます。 CP-67 ハイパーバイザーは、1967 年にはすでに仮想マシンと仮想化されたシステム イメージをサポートしていました。このハイパーバイザーでは、ディスク全体を複数の小さなディスクに仮想化できます。たとえば、カード リーダー、タイム クロック、プリンターなどのユニット記録デバイスは、実際の物理デバイスが存在しなくても仮想化できます。ハードウェアの観点から見ると、当時の System/360 Model 67 は仮想化デバイスをサポートしておらず、必要な仮想化を提供していたのは CP-67 ハイパーバイザー自体でした。ただし、CP-67 はメイン メモリを仮想化できないため、これを完了するには Model 67 の支援が必要です。

System/360 モデル 67 は、CP-67 によって作成されたテーブルを使用して動的アドレス変換 (DAT) を実装できます。このようにして、仮想マシン内の特定のメモリ ブロックを実際のメモリ内の任意のブロックにマップできます。実メモリ内で連続していないメモリ ブロックが、仮想マシン内で連続している場合があります。さらに興味深いのは、「仮想メモリ」内のブロックが実際のメモリにマップされない可能性があることです。代わりに、CP-67 によってディスク上のデータ ブロックにマップされ、参照された場合にのみ実際のメモリに読み込まれます。この設計により、クライアント オペレーティング システムはデータが常にメモリ内にあると認識します。これはいわゆるページング技術であり、仮想化技術の基礎でもあります。今日の z/os システムでは、このメカニズムを使用して、さまざまなアプリケーションとプログラムを分離します。

[[232822]]

トランスレーションルックアサイドバッファ（TLB）は実用的な

動的アドレス変換は素晴らしいアイデアですが、メモリ内の命令またはオペランド アドレスにアクセスするたびにアドレス変換が必要になると、かかる時間が許容できないものになります。メインフレームの命令のほとんどは複数のアドレスを伴うため、画期的なイノベーションがなければ、動的アドレス変換によってマシンの効率が低下します。この時、動的なアドレス変換を可能にする革新、つまりトランスレーション ルックアサイド バッファ (TLB) が登場しました。 TLB は、以前の翻訳の結果を記録し、すばやくアクセスできる構造です。

ここでは TLB のエンジニアリング設計についてはあまり詳しく説明しません。ただし、いくつか注意すべき点があります。 TLB は、一連のエントリを内容とする 2 次元配列です。図1-01に示すように、長さ32エントリ、幅4エントリのTLBです。各エントリには、変換された仮想アドレスと実アドレスが含まれます。インデックスとコンテンツアドレス可能メモリを使用すると、TLB から正しい以前の変換を取得できます。以前の変換が TLB にない場合は、他の電子機器がメモリ内のテーブルを読み取って変換を実行し、結果を後で使用するために TLB 内の対応する列に書き込みます。

TLB を大きくすると、メモリ内テーブルへのアクセス回数を最小限に抑えることができるので非常に便利です。しかし残念なことに、信号はより大きな構造を通ってより長い距離を移動する必要があるため、大規模な電子回路へのアクセス速度は非常に遅くなる可能性があります。さらに、コンテンツアドレスメモリに必要な回路の量は非線形に増加します。したがって、TLB は一般的に小さくなります。幸いなことに、実効容量を増やすためのいくつかのテクニックがあるので、非常に大きな TLB を使用する必要はありません。

図1-01 レベル1 TLB

TLB容量の最適化

当初は、命令アドレスとオペランド アドレスを変換するために単一の TLB が使用されていました。しかし、変換が必要な場所も 2 つあります。それは、命令フェッチ ロジックとオペランド アクセス ロジックです。容量を効果的に増やす方法の 1 つは、命令アドレスの処理用とオペランド アドレスの処理用に 2 セットの TLB を使用することです。命令を処理する TLB は通常、命令アクセス ロジックの近くに物理的に配置され、データを処理する TLB はオペランド アドレス ロジックの近くに配置されます。このような設計では、2 つの TLB 間の相互作用を維持するために追加のロジックが必要になりますが、効率性の向上がもたらされるため、追加コストに見合う価値があります。

他に実行できることは、TLB のレベル数を増やすことです。これらの追加レベルは、小さな高速 TLB が使用されていない場合にのみ使用されるため、大容量で低速のデバイスにすることができます。レベルを追加するこのアプローチは、プロセッサ キャッシュで何十年も使用されてきました。各サブレベルの容量は大きく、アクセスするにはより多くのサイクルが必要です。この目的のために、IBM のエンジニアは第 2 レベルの変換ルックアサイド バッファ (TLB2) を非線形の方法で実装しました。メモリ内の DAT テーブルは線形テーブルではなく、より複雑な多層構造になっています (図 2-01 を参照)。たとえば、2 レベルのテーブルでは、第 1 レベルのテーブルはセグメント テーブルと呼ばれ、第 2 レベルのテーブルへのメモリ マッピングのエントリが含まれます。 2 番目のレベルのテーブルはページ テーブルと呼ばれ、4K のメモリをマッピングするための 256 個のエントリが含まれています。

図2-01 ストレージ内のDATテーブル構造

最新の z システム プロセッサの TLB2 には、サイズが 1 MB のセグメントとサイズが 4 K のページの 2 種類のエントリがあります (図 2-02 を参照)。最上位レベルの TLB (TLB1) で変換が見つからない場合、TLB2 は 4KB ページ エントリによって提供される変換を検索します。見つからない場合、TLB2 は変換するアドレスをセグメント エントリで検索します。このエントリが見つかった場合、メモリ内のセグメント テーブルにアクセスせずに、対応するページ テーブルに直接アクセスできるため、メモリ内テーブルからの変換は使用されなくなります。したがって、TLB2 を使用すると、メモリ内のテーブルにアクセスすることによって追加の変換を実行したり、少なくともこれらのアクセスの数を減らしたりすることができます。

図2-02 第2レベルTLBの構造

TLB の有効容量を増やすもう 1 つの方法は、より大きなページをサポートして、特定の仮想アドレスをカバーするために必要なエントリの数を減らすことです。この機能は System z プロセッサでサポートされています。まず、Z10 プロセッサでは、TLB1 は引き続き 4KB のエントリをサポートしますが、TLB2 は 1MB のページ エントリを収容できます。これらの 1MB ページ エントリは、メモリ内テーブルにアクセスせずに、TLB1 に必要な 4KB エントリを作成できます。 z196 プロセッサでは、TLB1 はすでに 1MB のページ エントリをサポートできます。このプロセッサでは、1MB ページ エントリを処理するための特別なデータ TLB1 が追加され、命令 TLB1 も 4KB と 1MB の両方のページ エントリをサポートするように強化されています。 zEC12 では 2GB ページ エントリのサポートも導入されました。この構造には、いくつかの 2 GB ページ エントリを保持する小さなデータ TLB1 があり、いくつかの非常に大きなページ エントリは、DB2 バッファー領域と JAVA ヒープへの効率的なマッピングに使用されます。

仮想化の革新は続く

この概要では、z/VM 仮想マシンのゲスト仮想メモリのサポートについては説明しません。これを実現するために、System z プロセッサは 2 つのレベルの変換をサポートします。まず、クライアントの仮想アドレスがクライアントの実際のアドレスに変換されます。ただし、クライアントの実際のアドレスはホストの仮想アドレスであるため、ホストの実際のアドレスに変換する必要があります。ここではこのトピックについてこれ以上説明しませんが、クライアント テーブルの変換には追加のホスト変換も含まれるため、2 レベル変換には多くのテーブルへのアクセスが含まれることに注意してください。 z システム ハードウェアには、上位層の操作に対して透過的に実装される、より複雑な操作が多数実装されています。