とにかく、カーネルが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フィールドはどういう意味ですか？はDirectMapx86関連の実装の詳細です。さまざまなサイズのページのページマッピング使用量を測定します。カーネル別;これは、カーネルがページをさまざまなサイズの巨大なページにどれだけうまくマッピングできるかを示しています。これはnr_hugepages、カーネルが（ユーザースペースで使用される）hugepageプールにhugepageを持たないシステムでも、TLBのロードを減らすためにページマップをマージしようとするという事実に限定されません（try_preserve_large_page参照pageattr.c）。