プロセスが「x」だけのヒープを要求すると、Linuxによって割り当てられたメモリが実際に物理的に連続しているかどうかが混乱します。
私の現在の理解は次のとおりです。 Linuxのメモリ割り当て単位はページサイズです。デフォルトでは、ページサイズは4KBです。ページはRAM上で物理的に連続しています。
/proc/buddyinfoの出力から、合計メモリがグループ0、グループ1、...グループ10など、複数のグループに分かれていることがわかります。
各グループ「n」には、それぞれサイズが4 KB *（2 ^ n）の複数の物理的に連続したメモリページが含まれています。
したがって、グループ0には4 KBサイズのページが含まれ、グループ1には8KBサイズのページが含まれ、グループ2には16KBサイズのページが含まれます。
今、アプリケーションが12KBのメモリを要求し、グループ2から利用可能な空きページがないとします。
知りたい
この場合、グループ0とグループ1でそれぞれ1ページを使用してメモリ割り当て要求が成功しますか？それとも失敗しますか？
特定のグループ「n」のページが物理メモリに連続していますか？たとえば、グループ2が5つの利用可能なページを想定している場合、5つのページはすべて物理的に連続していますか（5 * 4 * 4 = 80 KBのRAM連続ブロック）。
ベストアンサー1
実際に物理的に連続していますか？
いいえ。これはとても簡単です！物理ページとプロセスメモリ間のマッピングはほぼランダムです。
この場合、グループ0とグループ1でそれぞれ1ページを使用してメモリ割り当て要求が成功しますか？それとも失敗しますか？
一般的に言うとうまくいきます（12kBは本当に小さいです。システムに連続したページがそれほど多くない場合、深刻な問題が発生します）。これがMMUの魔法です。必要に応じて実際のページを並べ替えることができます。必要なテーブルをコンパクトに保ち、使用可能なメモリをすばやく見つけるために、これらのマッピングをできるだけ「直接」にしようとしますが、連続したメモリが不足しても失敗することはありませんが、完全に使用されていないページで十分です。
特定のグループ「n」のページが物理メモリに連続していますか？たとえば、グループ2が5つの利用可能なページを想定している場合、5つのページはすべて物理的に連続していますか（5 * 4 * 4 = 80 KBのRAM連続ブロック）。
いいえ。特に、物理メモリとオペレーティングシステム間の仮想化によって、システムがネストされたページテーブルの別の層をどのように持つことができるかを考えると、さらにそうです。