Debian Linuxはなぜプロセスごとに最大128TiBの仮想アドレス空間を許可しているのに、64TiBの物理メモリしか許可しないのですか？

Question

私はただ読むここ：

プロセスあたり最大128TiBの仮想アドレス空間（2GiBではなく）

4GiB（またはPAE拡張機能を備えた64GiB）の代わりに64TiB物理メモリをサポート

何故ですか？つまり、物理メモリのサポートは、カーネルまたは現在のハードウェアによって制限されていますか？

実際にアドレス指定できる物理メモリの2倍の仮想メモリ領域が必要なのはなぜですか。

Gilles &#39;SO- stop being evil&#39; · Accepted Answer

これらの制限はDebianやLinuxによるものではなく、ハードウェアによるものです。アーキテクチャ（プロセッサとメモリバス）によって制限が異なります。

現在のx86-64 PCプロセッサでは、MMUは 48ビットの仮想アドレス空間を許可します。つまり、アドレス空間は256TBに制限されています。ユーザーランドアドレスからのカーネルアドレス。これにより、プロセスのアドレス空間用に128TBが残ります。

現在のx86-64プロセッサでは、物理アドレスは最大48ビットを使用できます、つまり最大256TBを使用できることを意味します。 AMD64アーキテクチャが導入されて以来、制限は徐々に高まっています（正しく思い出せば、40ビットから）。アドレス空間の各ビットは、配線とデコードロジックにコストがかかるため（プロセッサがより高価になり、速度が遅くなり、温度が高くなります）、ハードウェアメーカーはサイズを抑える動機を持っています。

Linuxでは、物理メモリをカーネルスペースに完全にマッピングできるため、物理アドレスは2 ^ 46までしか許可されません（したがって、64TBまでしか持てません）。 48ビットのアドレス空間があることに注意してください。カーネル/ユーザー用の1ビットは、カーネルアドレス空間用に47ビットを残します。その半分は最大で物理メモリを直接アドレスし、残りの半分はカーネルが必要なものをマップできるようにします。（Linuxは、同時に完全にマッピングできない物理メモリに対応できますが、これにより複雑さが増すため、必要なプラットフォームでのみ実行されます x86-32 with PAE などおよびLPAEを使用するarmv7）。

いくつかの理由により、仮想メモリが物理メモリよりも大きいと便利です。

これにより、カーネルは物理メモリ全体をマップし、仮想マップピン用のスペースを確保できます。
物理メモリのマッピングに加えて、スワップ、ファイル、デバイスドライバーのマッピングがあります。
マップされていないメモリを場所に置くと便利です。キャッチするガードページバッファオーバーフロー、 [〜＃〜] aslr [〜＃〜] によるマップされていない大きなゾーンなど。

lungj · Answer

理由はわかりませんが、物理メモリの2倍のアドレス空間をサポートすると便利な7つの理由が考えられます。

derobert · Answer

これらはハードウェアの制限です。現在のx86_64/AMD64ハードウェアでは、48ビットの仮想アドレスとさまざまなサイズ（実装によって異なります。たとえば、ここで使用しているワークステーションは36ビットしかサポートしていません）の物理アドレスを使用できます。 Linuxカーネルは、仮想アドレス空間を半分に分割します（カーネルに半分、ユーザー空間に半分を使用します。x86の場合と同じです）。

だからあなたは得る：

2⁴⁸バイト÷2 =2⁴⁷バイト= 128 TiB

実際の物理アドレスであるため、物理アドレスのサイズは多くの場合、小さくなります。ボード上のCPUとトレースラインのピン/パッド、トランジスタ、接続などを使用します。おそらくチップセットでも同じです。プロセッサコアまたはソケットの設計寿命にわたって考えられない量のRAMをサポートすることは意味がありません。これらすべてにコストがかかります。（それぞれに32個のDIMMスロットと64GiB DIMMがあっても、まだ2TiBしかありません。DIMMの容量が毎年2倍になっても、64TiBから5年は離れています。

Peter Cordes が指摘するように、人々は D XPoint などの不揮発性ストレージをメモリバスに接続しているため、アドレス空間が不足する可能性があります。新しいプロセッサでは、物理アドレス空間が48ビットに拡張されています。 Debian wikiが更新されていない可能性があります。