x86 アーキテクチャー上の Linux カーネルのデフォルトのメモリー・ページ・サイズは 4 KB でしたが、それはどのように計算されたのでしょうか? またその理由は?
36524 次
6 に答える
45
デフォルトのページ サイズは、CPU の MMU (メモリ管理ユニット) がサポートするものによって決まります。32 ビット プロテクト モードでは、x86 は次の 2 種類のページをサポートします。
- 通常のもの、4 KiB
- 巨大なもの、4 MiB
すべての x86 プロセッサがラージ ページをサポートしているわけではありません。Page Size Extension (PSE) 機能を備えた CPU が必要です。これには、Pentium より前のプロセッサは含まれません。事実上、現世代のすべての x86 CPU がそれを実装しています。
4 KiB は、他のアーキテクチャでも広く普及しているページ粒度です。このサイズは、32 ビットの仮想アドレスをページ ディレクトリ/テーブル内の 2 つの 10 ビット インデックスに分割し、残りの 12 ビットで 4 KiB のページ サイズになると主張できます。
于 2012-07-18T14:41:16.807 に答える
26
32 ビット アーキテクチャの 4KB の通常ページ サイズの設計は、実際には非常に興味深いものです :)
そして、それが合理的である理由を示すために、追加の回答を追加したいと思います。
x86 は「2 レベル ページ テーブル」を使用して、仮想メモリ アドレスを物理メモリ アドレスに変換します。
したがって、ページ ディレクトリとページ テーブルの両方に
エントリが含まれ、ページ サイズが
バイトであるとします。
アドレスを最大限に活用するために、次のものがあります。
ページ ディレクトリ/テーブルの各エントリは 4 バイト (32 ビット) を消費するため、次のようになります。
したがって、y = 12 で、バイト単位のページ サイズは= 
= 4KB になります。
では、「1 レベルのページ テーブル」はどうでしょうか。これは興味深いことです。論理的には、アドレス ルックアップに 1 つのページ テーブルを使用できるからです。
ページ ディレクトリにエントリが含まれ、それぞれがアドレスを対応するページにマッピングし、ページ サイズが
バイトであると仮定します。
繰り返しますが、アドレスを最大限に活用するには、次のものが必要です。
と：
y = 17 となり、ページ サイズは= 
= 128KB です。
また、「2 レベル ページ テーブル」バージョンでは、ページ ディレクトリとページ テーブルのサイズが異なる可能性があると主張する場合もあります。ただし、これは、複数のメモリ ページを占有するより大きなページ ディレクトリを使用することを意味します。悲しいことに、新しいユーザー プロセスが生成されるたびに、独自のページ ディレクトリに対して OS が連続するページを割り当てる必要がありますが、これは設計上エレガントではありません。
于 2014-06-30T12:39:10.657 に答える
18
序章
ページング仮想メモリ技術をサポートした最初の Intel プロセッサは、Intel 80386でした。プロセッサは、4 KB の単一ページ サイズをサポートしていました。1985 年にリリースされて以来、Intel がその特定のページ サイズを選択した理由を理解するには、その時期にさかのぼる必要があります。
Atlasは、ページ サイズが 3 KB のページングをサポートする最初のコンピューターであり、仮想メモリの設計に大きな影響を与え、関連する研究を動機付けました。このシステムは 1958 年から 1962 年にかけて設計されました。興味深いことに、80386 が設計されたのは約 20 年後であり、コンピューター (およびそれらが実行するワークロード) はその期間中に根本的に進化しましたが、80386 がサポートするページ サイズは Atlas がサポートするページ サイズにいくらか近いことに注意してください。時間！実際、その時代の多くのコンピューターは、0.5 ～ 5 KB の範囲のページ サイズを使用していました。当時の研究者は、仮想メモリ システム (ページングとセグメンテーション) の研究にかなりの労力を費やしました。
大きな疑問の 1 つは、最適なページ サイズはどれくらいかということでした。60 年代と 70 年代には、ページ サイズがアプリケーションのパフォーマンスに与える影響を調査および理解し、ページ サイズの選択方法に関するガイドラインを推奨または提供しようとする多数の著作が公開されました。出版されなかった論文は確かにたくさんあります。私の知る限り、これには Intel からの「... したがって、ページ サイズは 4 KB にする必要があります」という文書が含まれています。しかし、ページ サイズとページ サイズ (または複数のページ サイズ) を選択するプロセスに影響または相互作用する要因はよく知られているため、この回答で基本的なレベルで説明します。また、4 KB のページ サイズが妥当である理由についても特に説明します。
ページサイズの問題
ページング方式では、物理メモリはページ フレームと呼ばれる同じサイズのメモリの連続した領域のシーケンスとして編成されます (これがページングの特徴です1 )。各ページ フレームは、仮想ページと呼ばれる仮想アドレス空間の同じサイズのチャンクにマップできます。
Nページがバイト2で構成されていると仮定し(これは、ページ フレームNのサイズも定義によりバイトであることを意味します)、ページで構成される仮想アドレス空間を考えPます (つまり、ページ番号は {0, 1, 2, ... です)。 , P- 1} であり、仮想アドレスの総数はN* P) です。また、物理アドレス空間がFページ フレームで構成されているとします (つまり、ページ フレーム番号は {0, 1, 2, ..., F- 1} であり、物理アドレスの総数はN*Fです)。
仮想アドレスが与えられた場合、物理アドレスを決定するVAメカニズム (マッピング デバイスPA) が必要です。マッピング先であるか、マッピングされていない場合はページ フォールトを発生させる必要があります。マッピング デバイスは、どこかに保存されているデータ構造 (ページ テーブル) を使用してマッピングを実行します。割り当てられた仮想ページごとに、ページがどのようにマップされているか、および場合によってはいくつかの追加属性 (保護属性など) を説明するエントリが、そのテーブルに存在する必要があります。ご覧のとおり、ページ テーブル エントリの設計は、ページ サイズと相互作用します。Intel 80386 のページ テーブル エントリの設計については後で説明します。
仮想アドレスのサイズは log 2 ( N* P) で、物理アドレスのサイズは log 2 ( N* F) です。一部のビットはVAページ内のオフセットを表し、他のビットはページ番号を表し、マッピング デバイスを使用してページを識別します。
ページ サイズにはいくつのオプションがありますか? まあ、それはN*PまたはN*Fのいずれか小さい方までの 1 バイトからなる可能性があります。それは多くのオプションです。
ページサイズは2のべき乗が便利
仮想アドレス はVA、ページ番号とオフセットのペア ( PN、OFF) に相当します。翻訳プロセスは可能な限り効率的である必要があります。ページ内のバイトがアドレス空間内で連続していると、プログラマー3にとって便利です。このように、マルチバイト データ構造内の項目のアドレスは、データ構造のベース アドレスを構成する単一のアドレスに対する単純な算術演算で計算できます。これは、仮想アドレスの最下位 log 2 ( N) ビット (切り上げ) を使用してオフセットを表し、残りのビットを使用してページ番号を表すことによって実現できます。
が 2 の累乗でない場合N、これらのビットの値に応じて、オフセットとページ番号の間で共有されるビットがいくつかあります。2の累乗にすることNで、そのような複雑さはありません。そのため、2 のべき乗であるページ サイズを使用するのが適切です。ページングをサポートするすべての実際のプロセッサは、2 のべき乗であるページ サイズを使用します (ただし、アドレス指定可能性の単位は 8 ビットではない場合があります)。これは理にかなっています。しかし、正直なところ、これが本当に重要かどうかは明らかではありません。今日のテクノロジーを使用するかどうかに関係なく、Nは 2 の累乗であり、パフォーマンスやその他の関心のあるメトリックに測定可能な影響を与えない場合があります。実際、将来、ますます大きなページ サイズが必要になると、2 の累乗ではないページ サイズの方が優れている場合があります。しかし、これまでのところ、これは起こっていません。ここで強調したいのは、ページ サイズを 2 のべき乗にしないという設計オプションを自動的に無視してはならないということです。これは、将来の仮想記憶システムを研究する良い機会になると思います。
とにかく、4 KB ページの選択が 80 年代に行われたことを念頭に置くと、ページ サイズのこのような非常に小さな変動は (理論的にも実験的にも) ほとんど重要ではないことが示されました。そのため、2 の累乗のページ サイズの利便性が勝ったのです。これにより、考慮すべきページ サイズの数が指数関数的に減少します。しかし、私たちにはまだ幅広い選択肢があります。
小さいページ サイズを優先する
マッピング・デバイスはページのレベルで機能するため、オペレーティング・システムから見た割り当ての単位は仮想ページ4です。アプリケーションが 1 バイトだけを割り当てる必要がある場合でも、その 1 バイトに仮想ページ全体を割り当てるよう OS に指示する必要があります。この問題は内部フラグメンテーションと呼ばれます. 各アプリケーション (またはアプリケーションの各コンポーネント) には、ページ サイズのチャンクでメモリを割り当てる独自の仮想アドレス空間があります。各アプリケーションは、割り当てる単一のオブジェクトに対して単一のページを使用するのではなく、同じページからできるだけ多くのオブジェクトを割り当ててから、より多くのページを割り当てることが期待されます。ただし、ページ属性はページのレベルで機能するため、同じアプリケーションが複数のユーザー モード メモリ マネージャーを使用する可能性があり (複数の C/C++ ランタイムを使用する場合など)、アプリケーションが使用していないページの一部を共有することは困難です。他のアプリケーションでは、システム内の多くのページで内部断片化が発生する可能性があります。小さいページ サイズを使用すると、物理 (システム全体) および仮想 (プロセスごと) メモリの無駄な量を減らすことができます。
さらに、通常、アプリケーションはその存続期間中にさまざまなフェーズを経て、さまざまなフェーズでさまざまなメモリ要件を示します。たとえば、ページ サイズが 16 KB であるが、多くのアプリケーションが多くのフェーズで 10 KB 未満しか必要としない場合、物理メモリが大量に浪費され、メモリ不足の状況につながる可能性があります。 8 または 4 KB などの小さいページ サイズがサポートされている場合は回避されます。
コピー オン ライトのソフト ページ フォールトを処理するには、ページ サイズが小さい方が適しています。ページが小さいほど、そのコピーの作成にかかる時間が短くなるからです。ページ サイズが非常に小さい場合、メモリ バスの帯域幅によっては、測定可能な違いが生じない場合があります。
1970 年代のコンピューターで使用可能な物理メモリの一般的な量は、数十から数百キロバイトの範囲でした。数百 KB 以上のページ サイズは意味がありません。実際、当時のアプリケーションのワーキング セットは通常、数キロバイトから数十キロバイトしかありませんでした。そのため、わずか 16 KB のページ サイズでも実用的ではない可能性があります。ページ サイズは、物理メモリの量と一致している必要があります。もちろん、この議論は今日のシステムにも当てはまります (たとえば、128 GB のページを使用しても意味がありません)。
したがって、 70 年代から 80 年代前半のワーキング セットのサイズと物理メモリの可用性を考慮すると、ページ サイズは 2 0 ～ 2 14の範囲の 2 の累乗でなければなりません。これで、選択できるオプションは 15 個だけになりました。
より大きなページ サイズを優先する
また、ページ サイズが大きいほど優れていると主張することもできます。同じワーキング セットの場合、ページ サイズが小さいほど、アプリケーションあたりのページ数が多くなり、変換を有効にするためにページ テーブル エントリが必要になります。これには基本的に、ページ テーブルの構造に関係なく、より大きなページ テーブルが必要です (ただし、正確なオーバーヘッドはページ テーブル エントリ自体の設計に依存しますが、これについては後で説明します)。たとえば、4 バイトのページと数十 KB の典型的なワーキング セットがあるとします。その場合、物理メモリのほとんどは実際には、データではなくページ テーブルを保持するために割り当てられます。ページ テーブルをセカンダリ ストレージにページ アウトすると、個々のメモリ参照で二重のページ フォールトが発生し、パフォーマンスが大幅に低下します。そのようなデザインは明らかにばかげています。
基本的に、ページ サイズは、これまでに可能な最小のワーキング セット サイズよりも (大幅に) 小さくするべきではありません。これにより、サイズ 2 0 -2 6のページがすぐに除外され、8 つのオプションが残ります。70 年代と 80 年代初頭のページ サイズを研究した論文は、ほとんどの場合、これら 8 つのオプションのみを研究しています。
ページ サイズを大きくすると有利になる別の理由があります。仮想メモリの利点の 1 つは、メイン メモリに加えてセカンダリ ストレージを透過的に使用して揮発性データを保持できることです。ただし、セカンダリ ストレージ デバイスは機械的なものであり、バルク転送で最高のパフォーマンスを発揮します。これは実際にはガイドラインであり、まだページ サイズを除外するべきではありません。さまざまな設計と特性を持つデバイスがあり、最終的には、バルク転送のパフォーマンス上の利点はある時点で飽和します。しかし、ページ サイズがパフォーマンスに与える影響を測定する際には、これを考慮に入れる必要があります。考慮されているアプリケーションのタイプが空間的局所性をほとんど示さない場合でも、ディスクとの間で余分なバイトをコピーするのは必ずしも無料ではないため、小さいページ サイズが望ましいでしょう。
参照の空間的局所性により、特定のページ サイズの使用が促進されます。ページ サイズが非常に小さい場合、ページ内のすべてのバイトが短時間で使用される可能性が高くなります。ページのサイズが大きくなるにつれて、使用される可能性が低いバイト数が増加します。ただし、非常に大きなページの場合、局所性に関係なく、すべてのワーキング セットが少数のページに収まる場合があります。したがって、ページ フォールトの数を最小限に抑えるには、ページ サイズが小さすぎるか大きすぎる必要がありますが、その中間ではありません。しかし、最終的には、これはアプリケーションごとに異なります。オブジェクト指向プログラミングや関数型プログラミングなどの新しいプログラミング パラダイム また、マルチスレッドなどの手法は、リンクされた構造の広範な使用と、さまざまなアプリケーションが互いに相互作用する方法により、実際には空間的局所性を低下させる可能性があります。ページ フォールトの数を減らすには、ページ サイズを大きくすることをお勧めします。ただし、共有ページの内部断片化を減らすために、複数のアプリケーション間で共有されるメモリには小さいページ サイズが適している場合があります。また、メイン メモリに保持できるページ フレームの数がページ フォールトの数と相関し、ページ サイズが小さいほど好ましいことが実験的に示されています。
当時、TLB の必要性は十分に認識されていました。Intel はそれらを特許でページ キャッシュと呼んでいました (Intel が最初にその用語を使用したかどうかは不明です)。アドレス変換は命令実行のクリティカル パス上にあるため、高速 TLB は非常に重要です。可能な限り高速にするには、サイズを小さくする必要がありますが、キャッシュできるのは少数のページ テーブル エントリのみです。これにより、より大きなページ サイズを使用するようになります。
最適なページ サイズを検索すると、最適なページ サイズがないことが判明しました。その時点で、複数のページ サイズをサポートする必要があることが知られていました。実際、1965 年に設計された Multics システムは、64 または 1,024 ワードのページ (1 ワードは 36 ビット サイズ) をサポートしていました。2 7から2 14の範囲のページ サイズが、さまざまなシナリオで経験的にも理論的にも最適であることが示されました。Intel は、顧客が 80 年代に使用していたアプリケーションの平均パフォーマンスが最高になるのは 4 KB ページであることを認識していたに違いありません。今日のコンピューターとアプリケーションでは、70 年代と 80 年代のようにページ サイズがわずかに異なっていても、それほど大きな違いはありません。
Intel 80386 のページ テーブル エントリの設計
ページ ディレクトリ エントリとページ テーブル エントリの設計については、Intel の特許で詳しく説明されています。ページ テーブル エントリのサイズとページ テーブルの全体的な構造は、ページ サイズに関する多くの研究で考慮されているため、これは重要です。答えを短くするために、これについてこれ以上詳しく説明することは避けたいと思います。
近未来のページサイズ
Intel は数か月前に、デフォルトのページ サイズが 64 KB であると同時に、下位互換性のために 4 KB ページ (およびその他の IA-32e ページ サイズ) をサポートするシステムを明らかに提案する特許を取得しました。私は特許から引用します：
64 KB ページの 4 KB サブページへのマッピングのサポートの結果として、VA64 は、4 KB ページごとの独立した保護ビットおよび任意の 4 KB 整列アドレス マッピングを含む、4 KB ページで現在定義されているすべての操作を直接サポートします。VA64 は、OS カーネルが 64 KB 単位でメモリを割り当てる場合でも、4 KB 境界での OS カーネル ページ管理もサポートします。ラージ ページのサポートの結果として、VA64 は、Intel Corporation の IA-32e ページング システムなどの既存のページング システムがサポートするページへの仮想アドレス範囲のすべての分割をサポートします。したがって、VA64 は、4 KB ページの Windows® OS カーネルで動作するアプリケーションとハードウェア デバイスをサポートすると同時に、64 KB ページを使用できる場合は 64 KB ページを最大限に活用します。
VA64 の機能は、第 1 世代の VA64 対応 OS カーネルですべてをサポートする必要はなく、OS カーネルによって徐々に採用されます。たとえば、VA64 対応の OS カーネルは、すべてのページを現在のサイズ (たとえば、Intel Corporation の IA-32e ページング システムでは 4 KB/2 GB/1 TB) にマッピングすることから始めますが、新しいページ テーブル形式に変更します。ページ テーブル形式の変更後、OS カーネルを変更して仮想メモリを 64 KB 単位でマップし、64 KB ページを空きリストに格納するように変更できます。その後、OS カーネルは、アライメントと保護が許可されている場合はいつでも 64 KB ページの使用を開始し、他の VA64 機能のサポートを追加できます。
VA64 ページング システムについては、特許に書かれていること以外は何も知りません。インターネットのどこにも何もありません。もっとすぐにわかると思います。
選択された参考文献
デニング、PJ（1970）。仮想メモリ。ACM Computing Surveys Volume 2 Issue 3、153-189。
Gelenbe、E.、Tiberio、P.、およびBoekhorst、JCA（1973）。デマンド ページング システムのページ サイズ。Acta Informatica、3(1)、1-23。
Alanko, TO, & Verkamo, AI (1983). 仮想メモリ内のセグメンテーション、ページング、および最適なページ サイズ。性能評価、3(1)、13-33。
Corbató、FJ、およびVyssotsky、VA（1965）。Multics システムの紹介と概要。1965 年 11 月 30 日から 12 月 1 日にかけて開催されたコンピューター会議の議事録、パート I (pp. 185-196)。
脚注
(1) 実際には、単一の仮想ページのサイズはページ フレームのサイズの倍数になる可能性がありますが、そこには行きません。
(2) 定式化を一般化し、「ワード」という用語を使用して、バイトではなくメモリのアドレス指定可能な最小単位を指すことができますが、それはここでは重要ではありません。
(3) プログラミング言語によってはプログラマーではないかもしれませんが、コンパイラー、リンカー、アセンブラー、およびバイナリー・コードで動作するツール。
(4) ページングと非ページングの同時使用をサポートするシステムを設計することは確かに可能です。
于 2018-04-26T02:32:53.250 に答える
12
多くのアーキテクチャでは、デフォルトのページ サイズは 4 KB です。通常は、huge pageモードに切り替えることで増やすことができます (AMD64 の 1 GB のように、かなり大きくなる場合もあります)。これにより、ページ テーブルが小さくなり、パフォーマンスが向上する可能性があります。
于 2012-07-18T14:37:02.103 に答える
0
ウィキペディアの記事からこれを入手し、引用します。
ページ サイズは通常、プロセッサ アーキテクチャによって決まります。
以下の記事をご覧ください。
于 2012-07-18T14:36:12.037 に答える