オペレーティング システムおよび PAE のサポート

最終更新日: 2006年7月14日
**
関連リンク
**
トピック
PAE: 32 ビット システム vs. 64 ビット システムPAE: 32 ビット システム vs. 64 ビット システム
技術的な背景技術的な背景
オペレーティング システムの実装とアプリケーション サポートオペレーティング システムの実装とアプリケーション サポート
IA32 での大容量メモリ サポートの技術的な問題点IA32 での大容量メモリ サポートの技術的な問題点
Windows と PAEWindows と PAE

PAE: 32 ビット システム vs. 64 ビット システム

4 GB を超える物理メモリにアドレス指定するには、Intel (32 ビット) プロセッサの標準動作モードが提供する 32 ビット アドレス以上のものが必要です。このため、Intel は、Intel Pentium Pro プロセッサ以降、PAE と呼ばれる 36 ビットの物理アドレス指定モードを導入しました。

この記事では、PAE モード アドレス指定を使用するアプリケーションにサポートを提供するため、Microsoft Windows オペレーティング システムや複数の UNIX オペレーティング システムで用いられるいくつかの技法を説明します。これらの環境で動作するプロセスは 32 ビット ポインタを使用しているので、オペレーティング システムは、アプリケーションが PAE の 36 ビット アドレスを実際に使用できるのと同じ方法で、36 ビット アドレスを管理して提供する必要があります。主な問題は、どのようにしてオペレーティング システムがこの問題を解決するかです。パフォーマンス、機能、プログラミングの簡潔さ、およびこれらの問題点を処理する過程での信頼性により、大容量メモリ サポートの有用性は決まります。

PAE は、32 ビット バージョンの Windows オペレーティング システムでのみサポートされます。64 ビット バージョンの Windows は、PAE をサポートしません。64 ビット バージョンの Windows の、デバイス ドライバとシステム要件の詳細については、64 ビット システムの設計を参照してください。Address Windowing Extension (AWE) の API は、32 ビット システムでサポートされます。また、ネイティブ アプリケーションと WoW64 アプリケーションの両方に対して、x64 システムでもサポートされます。

一般的に、PAE メモリのサポートは 4 GB 以上の RAM のサポートと関連していますが、PAE は、ハードウェアによるデータ実行防止機能 (DEP) をサポートする Windows XP SP2、Windows Server 2003、およびそれ以降の 32 ビット バージョンの Windows で有効にできます。

この記事の情報は、Windows 2000、Windows XP Professional、Windows Server 2003、およびこれらのオペレーティング システムのそれ以降のバージョンに適用されます。これらの OS を、このペーパーでは "Windows" と総称します。

ページのトップへページのトップへ

技術的な背景

標準 32 ビット モードでのアドレス変換
すべての IA32 プロセッサ (Intel Pentium、Pentium Pro、Pentium II Xeon、および Pentium III Xeon) は、32 ビットの物理アドレス (4 GB) をサポートし、アプリケーションが実行中に 4 GB の仮想アドレスをアドレス指定するのを許可します。システムは、アプリケーションとオペレーティング システムが使用する 32 ビット仮想アドレスを、ハードウェアが使用する 32 ビット物理アドレスに変換する必要があります。(Pentium Pro は、PAE をサポートする IA32 ファミリの最初のプロセッサでした。ただし、36 ビット物理アドレスのチップ セット サポートも必要であり、それは通常欠けていました。)

Windows は、2 つのレベルのマッピングを使用して、変換を行います。変換は、メモリ マネージャが作成して維持するページ ディレクトリおよびページ テーブルと呼ばれるデータ構造セットによって容易になります。

PSE モード
IA32 は、4 GB (32 ビット) を超えるメモリにアクセスする 2 つの方法をサポートします。PSE (ページ サイズ拡張) はまず 1 つの方法で、Pentium II で導入されました。この方法は、4 バイトの PTE (ページ テーブル エントリ) サイズを保っているので、互換性の面で長所があります。ただし、その実用的な実装は、ドライバを通じてのみ可能です。このアプローチは、4 GB を超える読み取りと書き込みに必要なバッファ コピー操作により、パフォーマンスの制限をかなり受けます。PSE モードは、PSE 36 RAM ディスク利用モデルで使用されます。

PSE は、標準の 1K ディレクトリを使用します。また、ページ サイズが 4 MB を超えるページ テーブルは使用せず、このモードでは 1 レベルの間接性がありません。PDE (ページ ディレクトリ エントリ) は、14 ビットのアドレスを含んでおり、22 ビットのバイト インデックスと結合すると、36 ビットの拡張物理アドレスが生成されます。4 KB ページと 4 MB ページは両方とも、4 GB より下で同時にサポートされ、4 KB ページは、標準方法でサポートされます。

4 GB より上に位置するページは、PSE モード (4 MB ページ サイズ) を使用する必要がある点に注意してください。

PAE モード
PAE は、4 GB を超えるメモリにアクセスするためサポートされた第 2 の方法で、この方法は広く実装されました。PAE は、4 KB または 2 MB ページのいずれかを使用して、最大 64 GB の物理メモリを、32 ビット (4 GB) の仮想アドレス スペースにマップします。Page ディレクトリとページ テーブルは、8 バイト形式に拡張され、これにより、ページ テーブルとページ フレームのベース アドレスは、20 ビットから 24 ビットに拡張できます。ここで、追加の 4 ビットが導入され、36 ビットの物理アドレスが完成します。

Windows は、4 KB ページで、PAE をサポートします。また、PAE は、2 MB ページがサポートされるモードもサポートします。UNIX オペレーティング システムの多くは、2 MB ページのモードに依存しています。アドレス変換は、ページ テーブルを使用せずに行われます (PDE がページ フレーム アドレスを直接提供します)。

ページのトップへページのトップへ

オペレーティング システムの実装とアプリケーション サポート

次の問題点は、オペレーティング システムが、PAE の 36 ビット アドレスをどのように管理して提供できるかです。これは、32 ビット ポインタを使用するアプリケーションが追加メモリを実際に使用できるのと同じ方法で行われる必要があります。

これには、5 つのアプリケーション サポート モデルがあります。最初の 2 つのモデル (Server Consolidation と Large Cache) は、オペレーティング システム内で完全に処理され、アプリケーションへの変更は不要です。次の 2 つのモデル (Application Windowing と Process Fork) では、アプリケーションを変更して、大容量メモリ用の API 拡張機能をサポートする必要があります。最後のモデル (PSE 36 RAM Disk) では、オペレーティング システムへの変更は不要ですが (ドライバに実装済み)、ドライバをサポートするようアプリケーションを変更する必要があります。

1. Server Consolidation
PAE 対応オペレーティング システムは、複数のアプリケーションを読み込むため、システムによって提供される物理メモリをすべて利用できる必要があります。App#1、App#2、App #N など、複数のアプリケーションはそれぞれ、最大 4 GB の仮想アドレスから成ります。PAE に対応していないシステムでは、システム内の最大物理メモリが 4 GB に制限されているので、ページングが頻繁に起きる可能性があります。

PAE モードで追加の物理メモリをサポートすると、オペレーティング システムは、ページングなしで、より多くのアプリケーションをメモリ内に保つことができます。これは、サーバー統合構成をサポートする際に有用です。こうした構成では通常、単一のサーバーで複数のアプリケーションをサポートする必要があるからです。この機能をサポートするためアプリケーションを変更する必要はない点に留意してください。

2. Large Cache
また、データ キャッシュ用に、追加の PAE 対応メモリを使用することも可能です。オペレーティング システムがこの機能をサポートしている場合、これを活用するためアプリケーションを再コーディングする必要はありません。Windows Advanced Server と Datacenter Server は、PAE プラットフォームでキャッシュをサポートし、利用可能なメモリをすべて使用できます。

3. Application Windowing
PAE 対応オペレーティング システムでは、API を導入することにより、適切にコーディングされたアプリケーションは、システム内の任意の場所の物理メモリにアクセスできます。物理メモリが 4 GB を超えていても、それは可能です。理想的には、物理 "ハイ" メモリを割り当て、ウィンドウを作成または移動する API は、速くコーディングでき単純であるべきです。これは、メモリ内の大量のデータに高速アクセスする必要のあるアプリケーションでは、非常に有利です。

プロセス間でハイ メモリを共有すると、API と実装が、かなり複雑になる場合があります。Windows では、この種の共有を避けています。

さらに、ページングをサポートすると、オペレーティング システムの設計と実装がはるかに困難になり、確定的なパフォーマンスを達成しにくくなります。Windows では、ハイ メモリのページングも避けています。

4. Process Fork および Shared Memory
このアプリケーション サポート モデルでは、現在のプロセスを、複数のほぼ同一のコピーに分割します。コピーは、ユーザーとシステムのスタック、割り当てられたデータ領域、およびレジスタで構成されています。主な違いは、あるコピーには親のプロセス ID (PID) があり、他のコピーには新規の PID がある点です。フォークは、PID の値を返します。返される PID は、子であるコピーに対してはゼロで、親であるコピーに対しては子の PID です。

5. PSE36 RAM Disk
カーネル デバイス ドライバの使用により、オペレーティング システムをまったく変更しないでも、RAM ディスクによく似た、4 GB を超えるメモリを利用することは可能です。ページ テーブルが 4 バイト幅で保たれているので、基本オペレーティング システム (32 ビット モードで動作) とドライバ (PAE モードで動作) の間の互換性が維持されます。開発への影響は非常に少ない反面、次のような短所も複数あります。

ダブル バッファリングを実行するため強制されるすべての I/O により、パフォーマンスが低下する。

アプリケーション開発への影響は、現在の API に対する影響ほど小さくない。

すべてのアプリケーションが、4 GB の同じ物理メモリ領域を共有するので、"統合サーバー" として使用できない。

設計の実装
オペレーティング システムへの大容量メモリ サポートの実装を成功させるには、これらの問題点に直接対処する必要があります。オペレーティング システムの簡潔さ、信頼性、およびパフォーマンスは、これらの問題点を処理するため、どのような設計の選択を行ったかにより、直接影響を受けます。

ページのトップへページのトップへ

IA32 での大容量メモリ サポートの技術的な問題点

メモリ共有およびプロセス間通信
メモリの再マップが、プロセスへのメモリ割り当てで使用されるすべてのケースで、メモリ共有には問題があります (こうしたケースはさまざまな PAE で一般的です)。再マップされている物理メモリは、プロセスの仮想アドレス スペースの "外部" にあります。したがって、物理メモリは、プロセスの内部アクセスとセキュリティ制御が共有されており、オペレーティング システムが提供するアクセスとセキュリティ制御も共有されているという意味において、プロセスにあまり密着していません。

アクセスとセキュリティ制御を適用するには、オペレーティング システムのメモリ マネージャや、アプリケーション開発者が使用する必要のある API セットにおいて、メモリの追跡作業を大幅に増やす必要があります。これは、非常に高速な再マップ操作によって可能となる高パフォーマンスに、悪影響を及ぼします。また、物理的にマップされたどのメモリを各プロセスが使用しているかにかかわらず、どんな場合でも、プロセス間通信やメモリ共有が、2 つのプロセスの仮想アドレス スペース間で起こり得る点に注意することも重要です。

TLB シュート ダウン
変換ルック アサイド バッファ (TLB) は、ページ テーブル エントリの論理アドレスから物理アドレスへの直接マッピングを提供する、プロセッサ レジスタ (キャッシュ) です。いったん読み込むと、プロセッサは、タスク切り替えが生じない限り、ページ ディレクトリをほとんど読み取る (TLB ミス) 必要がありません。

再マップ操作中、すべてのプロセッサがチップ上で、論理アドレスから物理アドレスへの有効なマッピングを必ず保持するようにする必要があります。したがって、再マップ操作には、TLB シュート ダウンが必要です。なぜなら、論理アドレスから物理アドレスへの関連付けは、再マップによって無効にされるからです。ここで、"論理" とは、アプリケーション/プロセスから参照したメモリのビューを指します。

プロセッサが TLB を再び読み込む間、パフォーマンスには影響があります。すべてのオペレーティング システムにはこの問題点があり、PAE メモリ サポートの場合、各 OS は異なる方法でこの問題点に対処します。

Windows は、単一のアプリケーションに、必要な再マップ操作を "バッチ処理" する機能を提供します。これにより、すべては同時に起こり、(毎回パフォーマンスに影響する) ランダムな再マップではなく、TLB シュート ダウンとパフォーマンス低下が 1 回だけ生じます。これは、単一目的のシステムで通常実行される、大規模なアプリケーションにはかなり適切です。

他のオペレーティング システムは、"犠牲" バッファを提供するか、あるプロセスが別のプロセスのマッピングを共有できるようにします。ただし、この手法には、同期の回数が増え、API が複雑になるという短所があります。
また、Windows XP は、この "バッチ" 機能または Scatter/Gather 機能も提供します。さらに、これらの操作のパフォーマンスは、Windows Server 2003 Enterprise Edition と Datacenter Edition で向上しました。

I/O
さまざまな PAE はすべて、何らかのレベルで、付属のドライバにより、32 ビットおよび 64 ビットの DMA I/O デバイスをサポートします。ただし、これにはいくつか条件があります。

カーネルおよびメモリ構成
通常、カーネル メモリ領域の構成は、オペレーティング システムの標準カーネルと変わりません。多くの場合、メモリ プール サイズなどの項目は同じままです。下位互換性のため、PCI ベース アドレス レジスタ (BAR) は同じままです。メモリ サイズが大きいと、カーネル アドレス スペースの何らかの移動が起きます。これは通常、16 GB から 32 GB の間のメモリが、システム内に物理的に存在する場合です。

各オペレーティング システム間の 1 つの違いは、メモリ割り当てが動的かどうかです。

オペレーティング システムによっては、管理者が、キャッシュ、マッピング、統合など、さまざまな目的で使用されるメモリの量を構成する必要があります。

Windows では、使用している API の制約内でメモリ使用量が動的なので、管理者がメモリ割り当てを構成する必要はありません。

ハードウェアのサポート
PCI 標準は、高位 32 ビットのアドレスと低位 32 ビットのアドレスを 2 回に分けて送信することにより、4 GB を超えるメモリを、アダプタが物理的にアドレス指定できる方法を提供します。これは Dual Address Cycle (DAC) と呼ばれ、64 ビット アドレスを認識するが 32 のアドレス線しかない 32 ビット アダプタと、64 のアドレス線があるアダプタの両方で使用されます。これは、下位互換性のための機能です。

32 ビットを超えるメモリを PCI がアドレス指定する方法がある場合、わずかな障害モードがあります。2 つの 4 GB 領域に "またがる" 任意の I/O 範囲は、特別に扱う必要があります。そうしないと、アドレスの範囲は、転送の一部に対してのみ正しく解読され、残りの部分は、正しくないメモリの場所に転置されます。これにより、メモリが破損し、システムのクラッシュ、アプリケーションのクラッシュ、またはその場所でのデータの密かな破損が生じます。アプリケーションは、仮想アドレスのみ提供されており、物理レベルで参照できないので、これを防ぐことができません。PAE を使用するすべてのオペレーティング システムは、この問題に直面します。ただし、一部の OS は、これが生じるのを明示的に防がず、代わりに、デバイス ドライバによって正しい操作を行います。

ただし、Windows は明示的にこの問題を防ぎます。I/O 範囲がこのようにまたがっている場合、Windows はデバイスとドライバに、2 つの別個のアドレスと範囲を返します。最後の特別なケースは、4 GB からそれを超えた範囲への最初の切り替えです。DAC は、4 GB より下の領域には不要です。ただし、DAC は、残りの転送には必要です。ここでも、Windows は、メモリ破損を防ぐため、こういった場合、2 つの別個のアドレスと範囲を返します。

明らかに、DAC または 64 ビット アダプタとドライバは、I/O のバッファ処理が生じないとき、パフォーマンスが最良となります。ただし、アダプタとドライバが 32 ビットを超えるアドレス情報を利用できない場合は常に、このバッファ処理は必須です。PAE モード アドレス指定を利用するオペレーティング システムはすべて、下位互換性機能として、この "ダブル バッファリング" を何らかの方法でサポートします。このバッファ処理には、複数の要因に依存するパフォーマンスの低下があります。

アダプタ ハードウェアのパフォーマンス

ドライバのパフォーマンス

オペレーティング システムによるダブル バッファリングのサポート

システムにインストールされている物理メモリの量

物理メモリが増えるにつれ、32 ビットを超える I/O アドレスの相対量も、32 ビットより下の I/O アドレスに対して増加します。大半の場合、オペレーティング システムは、ダブル バッファリングを透過的に提供します。ただし、一部の Unix は、この機能に支援を提供せず、32 ビット デバイスとドライバが、独自のダブル バッファリング ルーチンと割り当てを管理する必要があります。

ドライバに関する問題点
通常、デバイス ドライバは、いくつかの小規模な範囲で変更する必要があります。実際のコード変更は小規模であっても、それは困難な場合があります。なぜなら、PAE メモリ アドレス指定を使用していない場合、デバイス ドライバは、物理アドレスの制限と 32 ビット仮想アドレスの制限が同じであると仮定する可能性があるからです。PAE メモリを使用すると、この仮定は誤りとなります。

以前、安全に使用できたいくつかの仮定とショートカットは、適用できなくなります。一般に、それらは 3 つのカテゴリに分かれます。

共有メモリ バッファを割り当てて配置するコード内のバッファ配置は、物理アドレスの上位 32 ビットを無視しないよう、変更する必要があります。

アドレス情報が保たれている可能性のある多くの場所でのアドレス情報の切り捨ては、避ける必要があります。

DMA 操作が、ランダムなメモリの場所に、またはその場所から情報を転送しないよう、仮想アドレス参照と物理アドレス参照を厳密に分ける必要があります。

PAE モードは、ハードウェア強制の DEP をサポートする、Windows XP SP2、Windows Server 2003 SP1、およびそれ以降のバージョンの Windows で有効にできます。ただし、これらのシステム用に設計されたデバイス ドライバの多くは、PAE が有効なシステム構成でテストされていない可能性があります。影響をデバイス ドライバの互換性に制限するため、ハードウェア アブストラクション レイヤ (HAL) への変更を、Windows XP SP2 と Windows Server 2003 SP1 Standard Edition で行い、物理アドレス スペースを 4 GB に制限しました。ドライバ開発者の方は、DPE に関してこちらのページを参照することをお勧めします。

ページング
PAE をサポートする大半のオペレーティング システムは、4 GB を超える物理メモリに対して、何らかの仮想メモリ ページングをサポートします。これは通常、ブート/システム ページング ファイルを 4 GB に制限したり、ページング ファイルを複数のオペレーティング システム構成のボリューム (必ずしも物理スピンドルではない) に展開したりするなど、いくつかの制限付きで実現します。

これにより仮想メモリの明白な利点が得られますが、欠点は、下記の 1 つ以上の特性を持つアプリケーションへのパフォーマンスの影響です。

大量の物理メモリを独自のデータ セットに使用している

多くの I/O 処理が行われる

大きな実行可能ワーキング セットがある

最後に、ページング サポートには通常、API セットの増加や、開発とバージョン移行の遅延という犠牲が伴います。

ユーザー API
PAE をサポートするすべてのオペレーティング システムには、IA32 プロセッサで可能な仮想アドレス範囲を超えて、プロセスが物理メモリを使用できる API があります。これらは主に、メモリ共有、プロセス間通信、ページングなど、前に説明した項目に対して、各 OS がどれだけのサポートを提供するかによって異なります。容易でシンプルな API セットは、Windows が提供する Address Windowing Extensions (AWE) API セットで、5 つの API 呼び出しのみから成ります。最も複雑な API は、その 4 倍大きく、カーネル レベルとユーザー レベルの呼び出しが含まれています。

専用の API が増えると (その一部はプロセッサのアーキテクチャにカーネル レベルで直接結びついています)、ある Unix 形式から別の Unix 形式にアプリケーションを移植するのが、高価になり、所要時間が増し、パフォーマンスの最適化とコストのバランスをとるための絶え間ない苦労が生じます。Windows は、シンプルかつ高速で、32 ビットと 64 ビットのハードウェア プラットフォーム間で完全に移植可能で、再コンパイルするだけで機能する API セットを提供します。

ページ サイズ
4 GB を超える物理メモリをアプリケーションに提供する場合、PAE をサポートするほぼすべてのオペレーティング システムは、さまざまなページ サイズを使用します。その主な例外は、Windows です。Windows は、IA32 プラットフォームで、4 KB ページしかアプリケーションに提供しません (これは Itanium ベースのプラットフォームでは異なります)。

さまざまなページ サイズをアプリケーションで使用する場合の問題点は、さまざまなメモリ割り当てサイズでアプリケーションが正しく機能するため必要な、追加の複雑さと関連しています。また、ほぼすべてのアプリケーションがページ サイズに関して行う基礎的な仮定によって生じる、微妙な影響とも関連しています。調査によると、少数のアプリケーションは、2 MB や 4 MB など、ページ サイズが大きいと利点があることが示されていますが、各 TLB エントリはより大きなアドレス範囲にわたっているので、一般的にアプリケーションにとって、大きなページ サイズによる利点はありません。

ページのトップへページのトップへ

Windows と PAE

Windows のバージョンサポート

Windows 2000 Professional
Windows XP

AWE API と 4 GB の物理 RAM

Windows XP SP2 およびそれ以降

AWE API と 4 GB の物理アドレス スペース

Windows 2000 Server
Windows Server 2003, Standard Edition

AWE API と 4 GB の RAM

Windows Server 2003 SP1, Standard Edition

AWE API と 4 GB の物理アドレス スペース

Windows Server 2003, Enterprise Edition

8 個のプロセッサと 32 GB の RAM

Windows Server 2003 SP1, Enterprise Edition

8 個のプロセッサと 64 GB の RAM

Windows 2000 Advanced Server

8 個のプロセッサと 8 GB の RAM

Windows 2000 Datacenter Server

32 個のプロセッサと 32 GB の RAM (64 GB のサポートは、テスト用システムがないため提供されませんでした)

Windows Server 2003, Datacenter Edition

32 個のプロセッサと 64 GB の RAM

Windows Server 2003 SP1, Datacenter Edition

32 個のプロセッサと 128 GB の RAM

開発者向けのガイドラインなど、PAE と Windows の詳細については、PAE メモリと Windows を参照してください。


ページのトップへページのトップへ