ホームページ >システムチュートリアル >Linux >Linux システムのデフォルトのページ サイズが 4KB である理由

Linux システムのデフォルトのページ サイズが 4KB である理由

WBOY
WBOY転載
2024-02-05 16:27:021108ブラウズ

ご存知のとおり、Linux はページ単位でメモリを管理します。ディスクからメモリにデータをロードする場合でも、メモリからディスクにデータを書き戻す場合でも、オペレーティング システムはページ単位で動作します。つまり、1 バイトのデータをディスクに書き込むだけの場合、オペレーティング システムはフラッシュする必要もあります。ページ全体のすべてのデータをディスクに書き込みます。

Linux では、操作に通常サイズのメモリ ページを使用することも、巨大なメモリ ページ (ヒュージ ページ) を使用することもできることに注意してください。ただし、ほとんどのプロセッサのメモリ ページのデフォルト サイズは 4KB です。ただし、一部のプロセッサでは、デフォルトのページ サイズは 8KB、16KB、または 64KB。通常のメモリ ページ サイズに加えて、プロセッサごとに異なる巨大ページ サイズがサポートされます。たとえば、x86 プロセッサでは、2MB サイズのメモリ ページを使用できます。

4KB メモリ ページは歴史的な遺物となっており、このページ サイズは 1980 年代から広く採用され、現在でも残っています。現在のハードウェアは昔に比べて豊かになっていますが、依然として過去から受け継がれている 4KB のメモリ ページ サイズにこだわっています。通常、次の図に示すように、メモリを取り付けるときにメモリ モジュールの仕様を明確に確認できます。

为什么 Linux 系统默认页大小是 4KB図 1 – ランダム アクセス メモリ

現在、4KB のメモリ ページ サイズは最良の選択ではない可能性があります。8KB または 16KB の方が適切な選択かもしれませんが、これは特定のシナリオで過去に行われたトレードオフです。この記事では、4KB という数字にあまりこだわりすぎず、この結果を決定するいくつかの要因にもっと注意を払い、同様のシナリオに遭遇したときにこれらの側面から最善の選択を検討できるようにする必要があります。この記事では、メモリ ページ サイズに影響を与える次の 2 つの要素を紹介します。

ページ サイズが小さすぎると、ページ テーブル エントリが大きくなり、TLB (変換ルックアサイド バッファ) の検索速度が増加し、アドレス指定時のオーバーヘッドが増加します。

ページ サイズが大きすぎると、メモリ領域が無駄になり、メモリの断片化が発生し、メモリ使用率が低下します;

前世紀では、メモリ ページ サイズを設計する際に上記 2 つの要素が十分に考慮され、最終的にオペレーティング システムの最も一般的なページ サイズとして 4KB メモリ ページが選択されました。上記はオペレーティング システムのパフォーマンスに影響します。

ページテーブルエントリ Linux の仮想メモリについては、「Linux に仮想メモリが必要な理由」の記事で紹介しました。各プロセスが認識できるのは、独立した仮想メモリ空​​間です。仮想メモリ空​​間は論理的な概念にすぎません。プロセスは依然として仮想メモリにアクセスする必要があります。メモリは物理メモリに相当し、仮想メモリから物理メモリへの変換には各プロセスが保持するページテーブルを使用する必要があります。

128 TiB 仮想メモリのマップされたデータを 64 ビット オペレーティング システムに保存するために、Linux は 2.6.10 で仮想アドレス変換を支援する 4 層ページ テーブルを導入し、5 層ページ テーブル構造が導入されました。 4.11 で導入されました。将来的には、64 ビット仮想アドレスをサポートするために、より多くのページ テーブル構造の層が導入される可能性があります。

図 2 – 4 層のページ テーブル構造为什么 Linux 系统默认页大小是 4KB

上図に示す 4 層のページ テーブル構造では、オペレーティング システムは最下位 12 ビットをページ オフセットとして使用し、残りの 36 ビットは 4 つのグループに分割され、前のレベルの現在のレベルを表します。すべての仮想アドレスは、上記の多層ページ テーブルを使用して、対応する物理アドレスを見つけることができます。

オペレーティング システムの仮想アドレス空間のサイズは決まっているため、仮想アドレス空間全体が同じサイズの N 個のメモリ ページに均等に分割されるため、メモリ ページのサイズが最終的にページ テーブルのレベルを決定します。各プロセスのエントリの構造と特定の数、仮想ページのサイズが小さいほど、単一プロセス内のページ テーブル エントリと仮想ページの数が多くなります。

PagesCount=仮想メモリ ÷ ページサイズ

現在の仮想ページのサイズは 4096 バイトであるため、仮想アドレスの末尾の 12 ビットは仮想ページ内のアドレスを表すことができます。仮想ページのサイズが 512 バイトに縮小されると、元の 4-レベル ページ テーブル構造または 5 レベル ページ テーブル構造 階層化されたページ テーブル構造は 5 層または 6 層になり、メモリ アクセスの追加オーバーヘッドが増加するだけでなく、各プロセスでページ テーブル エントリが占有するメモリ サイズも増加します。 。

断片化

メモリ マッピング デバイスはメモリ ページ レベルで動作するため、オペレーティング システムはメモリ割り当ての最小単位が仮想ページであると認識します。ユーザー プログラムが 1 バイトのメモリしか適用しない場合でも、次の図に示すように、オペレーティング システムはそのメモリ ページの仮想ページを適用します。メモリ ページのサイズが 24KB の場合、1 バイトのメモリを適用すると、スペースの ~99.9939% が無駄になります。

为什么 Linux 系统默认页大小是 4KB

図 3 – 大規模メモリの断片化

メモリ ページ サイズが大きくなると、メモリの断片化がますます深刻になります。メモリ ページが小さいと、メモリ空間内のメモリの断片化が減少し、メモリの使用率が向上します。前世紀には、メモリ リソースは今日ほど豊富ではありませんでした。ほとんどの場合、メモリはプログラムの実行を制限するリソースではありません。ほとんどのオンライン サービスは、メモリではなく、より多くの CPU を必要とします。ただし、前世紀においてメモリは実際には希少なリソースであったため、希少なリソースの利用率を向上させることを考慮する必要があります。

为什么 Linux 系统默认页大小是 4KB図 4 – メモリの価格

1980 年代と 1990 年代のメモリ スティックはわずか 512 KB または 2 MB で、価格は途方もなく高価でした。しかし、今日では数 GB のメモリが非常に一般的であるため、メモリ使用率は依然として非常に重要ですが、メモリの価格は今日、大幅な削減により、断片化されたメモリは解決すべき重要な問題ではなくなりました。

メモリ使用量に加えて、メモリ ページが大きくなると、メモリ コピーのオーバーヘッドも増加します。Linux のコピーオンライト メカニズムにより、複数のプロセスが同じメモリを共有する場合、プロセスの 1 つが共有メモリを変更すると、仮想メモリはメモリ ページのコピーをトリガーしますが、このとき、オペレーティング システムのメモリ ページが小さいほど、コピー オン ライトによって生じる追加のオーバーヘッドも小さくなります。

要約

上で述べたように、4KB メモリ ページは前世紀に決定されたデフォルト設定です。今日の観点から見ると、これはおそらく間違った選択です。Arm64、ia64 およびその他のアーキテクチャはすでにそれをサポートしています。8KB、16KB、およびメモリの価格がますます低くなり、システム メモリがますます大容量になるにつれて、オペレーティング システムにとってより大きなメモリがより良い選択になる可能性があります。メモリ ページ サイズを決定する 2 つの要素を確認してみましょう:

    ページ サイズが小さすぎると、ページ テーブル エントリが大きくなり、TLB (変換ルックアサイド バッファ) の検索速度が向上し、アドレス指定時のオーバーヘッドが増加しますが、プログラム内のメモリの断片化が減少し、メモリ使用率も向上します。
  • # ページ サイズが大きすぎると、メモリ領域が無駄になり、メモリの断片化が発生し、メモリ使用率が低下しますが、プロセス内のページ テーブル エントリと TLB アドレッシング時間を削減できます;
  • 最後に、関連する比較的未解決の質問をいくつか見てみましょう。興味のある読者は、次の質問について慎重に検討してください。
  • Linux のセクター、ブロック、ページ間の違いと接続は何ですか?

Linux ではブロック サイズはどのように決定されますか?一般的なサイズは何ですか?

以上がLinux システムのデフォルトのページ サイズが 4KB である理由の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。

声明:
この記事はlxlinux.netで複製されています。侵害がある場合は、admin@php.cn までご連絡ください。