c++如何读取系统的内存分页大小与配置信息【实战】

C++如何读取系统的内存分页大小与配置信息【实战】

在系统编程和性能调优中，内存分页大小是个绕不开的基础参数。但这里有个常见的误区：系统实际使用的基础分页大小，可不是靠猜或者查查文档就能确定的，必须得在运行时获取。下面这个核心事实，是很多问题的根源：

getpagesize() 返回 Linux 系统实际使用的硬件基础页大小（通常 4096 字节），是 mmap/mprotect 等调用唯一可靠的对齐依据；它不随透明大页或 hugetlb 配置变化，大页信息需查 /proc/meminfo 或 /sys/kernel/mm/。

理解了这一点，我们再来看看具体怎么操作。

Linux 下用 getpagesize() 获取内存分页大小最可靠

说到获取页大小，getpagesize() 函数无疑是首选。它是 POSIX 标准函数，直接返回当前进程所在系统的硬件页大小（单位是字节）。它的好处在于，不依赖 /proc 文件系统或者 sysctl，更不会受到透明大页（THP）或巨页（hugetlb）配置的干扰。换句话说，它是唯一能真实反映 mmap、mprotect 这些系统调用底层对齐要求的那个值。

这里必须划个重点：getpagesize() 返回的是“基本页大小”，跟透明大页或者 hugetlb 的大小是两码事。它也不会因为你在 mmap() 时用了 MAP_HUGETLB 标志而改变——那是另一套独立的机制。

用起来很简单：

#include 
#include 

int main() {
    std::cout << "page size: " << getpagesize() << " bytes\n";
    return 0;
}

• 在 x86_64 架构的 Linux 上，它通常输出 4096。
• 即使系统启用了 2MB 的透明大页（THP），getpagesize() 依然会返回 4096。因为 THP 是内核在背后自动合并小页的优化手段，并不会改变用户态可见的页粒度。
• 如果你需要获取大页的具体信息（比如 2097152 字节，即 2MB），那就得去查 /proc/meminfo 或者 /sys/kernel/mm/ 了。

读取 /proc/meminfo 获得分页相关配置状态

想了解内存分页的实时行为？/proc/meminfo 这个文件就是最直接的观察窗口。它清晰地展示了内核是否启用了透明大页、当前用了多少大页等关键状态。

立即学习“C++免费学习笔记（深入）”；

在解析这个文件时，有几个字段值得特别关注：

• MemTotal：物理内存总量。虽然它本身和分页无关，但经常被误当作依据。
• AnonHugePages：当前被透明大页（THP）映射的匿名内存大小（单位是KB）。如果这个值大于0，那就说明 THP 正在发挥作用。
• HugePages_Total：这是显式配置的 hugetlb 大页总数，需要手动通过命令（如 echo N > /proc/sys/vm/nr_hugepages）来设置。
• Hugepagesize：当前 hugetlb 使用的大页大小，后面会带单位，比如 2048 kB。

实际操作时，建议这么做：

• 使用 std::ifstream 逐行读取 /proc/meminfo，按冒号分割键和值，记得跳过空行。
• 别依赖字段出现的顺序，最好每行都完整匹配前缀。例如，可以用 line.substr(0, 15) == "AnonHugePages:" 这样的方式。
• 注意，Hugepagesize 字段末尾带有单位（kB 或 MB），解析后需要转换成字节。

检查 /sys/kernel/mm/transparent_hugepage/ 控制开关

想知道透明大页是不是真的启用了？光看 AnonHugePages 还不够，还得确认内核的开关状态。/sys/kernel/mm/transparent_hugepage/ 这个目录下的几个文件，直接决定了 THP 的行为：

• enabled：它的值可能是 [always] madvise never，方括号 [] 里包着的就是当前生效的策略。
• defrag：这个开关控制内核是否会主动整理内存来满足 THP 的分配，它会影响性能的抖动。
• shmem_enabled：决定是否对 tmpfs/shmem 启用 THP，这个功能在较新的内核中才有。

读取方式就是普通的文件操作：

std::ifstream f("/sys/kernel/mm/transparent_hugepage/enabled");
std::string line;
if (std::getline(f, line)) {
    // 解析出中括号内的值，例如 "[always]" → "always"
}

有几点需要注意：

• 这个路径下的文件默认只有 root 用户可以写，但所有用户都可以读。
• 在某些容器环境（比如 Docker 的默认配置）里，这个路径可能会被挂载为只读。这时 open() 能成功，但 read() 可能返回空内容，所以代码里要做好容错处理。
• 当值是 madvise 时，只有程序显式调用了 madvise(addr, len, MADV_HUGEPAGE)，才可能触发 THP。

Windows 下没有等价的 getpagesize()，要用 GetSystemInfo()

到了 Windows 这边，情况就不同了。它没有类 Unix 的 getpagesize() 函数。内存页大小信息，需要通过调用 GetSystemInfo() 来获取，这个函数会填充一个 SYSTEM_INFO 结构体，其中的 dwPageSize 字段给出了当前会话的“分配粒度”（allocation granularity），通常是 64KB。但这里有个关键点：实际的内存保护/提交单位，仍然是 4KB。

几个关键事实需要厘清：

• dwPageSize 并不等于硬件页大小。在 x86/x64 架构上，硬件页始终是 4KB。这个字段实际上是 VirtualAlloc 分配内存时的最小对齐单位。
• 真正用于 VirtualProtect 设置内存保护的最小粒度是 dwAllocationGranularity（通常也是 64KB），但页面保护本身生效的单位，依然是 4KB。
• 如果想获取真实的硬件页大小，在 Windows 上通常只能查阅文档或硬编码。对于 x86/x64，就是 4096；对于 ARM64，可能是 4096 或 16384，这需要在运行时判断 CPU 类型。

所以，在编写跨平台代码时，千万别试图统一“页大小”的语义。在 Linux 上，用 getpagesize() 来指导 mmap 的对齐；在 Windows 上，用 GetSystemInfo().dwAllocationGranularity 来指导 VirtualAlloc 的地址对齐。两者的目的不同，绝对不能混用。

最后，再提一个容易忽略的点：即使你从 /proc/meminfo 里查到了 Hugepagesize 是 2MB，也绝对不能直接用它去替代 getpagesize() 做常规的内存对齐。因为大页需要显式申请（通过 mmap 加 MAP_HUGETLB 标志）、需要预分配，而且失败的概率比常规分配要高得多。日常的 malloc 或普通 mmap，依然是以基本页为基础的。