とにかく、カーネルがhugepagesを使用しているようですが、なぜ特定のカーネルパラメータを使用して予約するhugepagesの数を指定しますか?
みんな/proc/meminfo
を見せた後DirectMap4K
、、DirectMap4M
の値は、DirectMap1G
ページサイズごとに存在するページテーブルエントリの数を表します。。したがって、明らかに4KiBより大きいページが使用されています。
友人はなぜ/proc/sys/vm/nr_hugepages
まだ存在するか。
答え1
nr_hugepages
あなたが言及した他の価値を補うので、まだ存在します。これカーネル文書すべての詳細がありますが、デフォルトでは/proc/sys/vm/nr_hugepages
カーネル hugepage プールにあるデフォルトサイズの永続的な hugepage の数を表示します (サイズはHugePages_Total
に表示されます/proc/meminfo
)。nr_hugepages
管理者が制御する設定で、hugepages
起動時にカーネルパラメータを使用するか、実行時に書き込みによって定義されますnr_hugepages
(システムが要求された大容量ページ数を提供できる場合)。
目的nr_hugepages
は、大きなページを使用できるようにすることです。ユーザー空間プログラムへ、渡す hugetlbfs
または共有メモリまたはmmap
割り当てられたページ数渡す nr_hugepages
この目的のために予約された hugepages プールを構成します。システムリソースが許可する場合は、より多くのhugepagesを使用できますが(最大設定nr_overcommit_hugepages
)、これは保証されません。大きなページをサポートするすべてのプラットフォームで動作します。これらのページは、過度のメモリ割り当てを実行するプログラムに便利ですが、制約に従います。特に交換はできません。
で述べたようにLinux "/proc/meminfo"ファイルのHardwareCorrupted、DirectMap4k、およびDirectMap2Mフィールドはどういう意味ですか?はDirectMap
x86関連の実装の詳細です。さまざまなサイズのページのページマッピング使用量を測定します。カーネル別;これは、カーネルがページをさまざまなサイズの巨大なページにどれだけうまくマッピングできるかを示しています。これはnr_hugepages
、カーネルが(ユーザースペースで使用される)hugepageプールにhugepageを持たないシステムでも、TLBのロードを減らすためにページマップをマージしようとするという事実に限定されません(try_preserve_large_page
参照pageattr.c
)。