c - メモリの断片化が 64 ビット マシンで問題になるのはなぜですか?

Question

32 ビット マシンでは、各プロセスが 4GB の仮想空間を取得します。この場合、断片化による問題が発生するのではないかと心配することができます。しかし、64 ビット マシンの場合、理論的には巨大なアドレス指定可能な仮想メモリがあるのに、64 ビット マシンでメモリの断片化がまだ問題になるのはなぜでしょうか?

Answer 1

アクセスしようとする各仮想アドレスは、オペレーティング システムによって物理メモリにマップされます。物理メモリはページ単位で割り当てられます (例: 4K サイズ)。オフセット 1000000*n でバイトを割り当て、1 から 1000000 までの n に対してそれを行うことができた場合 ( mmap でそれを行うことができると思います)、OS はそれを 100 万ページの物理メモリでバックアップする必要があります。 4Gのようなもの。その物理メモリは、他の用途には使用できません。バイトを連続して割り当てた場合、100 万バイトに対して約 1M の物理メモリ (256 ページ) しか必要ありません。

正当な理由で 4G を割り当て、その一部を割り当て解除して、すべてのページを少しずつ割り当てたままにすると、同様の悪い状況に陥る可能性があります。完全に解放された物理ページがないため、OS は解放されたメモリを他の目的で実際に再利用することはできません。これが断片化の問題です。

理論的には、仮想アドレス 1000000 と 2000000 が物理メモリの同じページにマップされ、断片化が回避されると想像できます。しかし実際には、正当な理由により、仮想メモリのマッピングはページごとに行われます。詳細については、http: //en.wikipedia.org/wiki/Page_tableを参照してください。

Answer 2

そのメモリはすべて「浪費」されているため、多くの内部フラグメンテーションがあるアプリケーションを考えてみてください。このプロセスでは、ワーキング セットがメモリ内に散らばっているため、メモリ内により多くのページが必要になります。つまり、メモリ フットプリントがはるかに大きくなります。このアプリケーションが RAM の物理スロットをめぐって競合している場合 (一般的なホーム セットアップでは、マシンにはまだ約 4 ～ 8 GB の RAM しかありません)、より多くのページ スワッピングが発生します。一般に、アプリケーションのメモリ フットプリントを減らして、メモリの負荷や他のアプリケーションとの競合を回避します。

実際には問題にならない場合もありますが、あちこちで余分なメガバイトを使用しても問題はありませんが、大規模なアプリケーションではすべてが加算されます。コードの内容やプロジェクトの目的に応じて、断片化をできるだけ少なくすることが重要かどうかは状況によって異なります。