大页内存/普通内存CPU缓存映射差异及性能测试异常原因咨询

• CPU型号: Intel(R) Xeon(R) CPU E5-2667 v3 @ 3.20GHz

• 步进: 2

• CPU主频: 3200.000 MHz

• CPU最高主频: 3200.0000 MHz

• CPU最低主频: 1200.0000 MHz

• BogoMIPS: 6391.94

• 虚拟化支持: VT-x

• L1d缓存: 32K

• L1i缓存: 32K

• L2缓存: 256K

• L3缓存: 20480K

• 操作系统内核版本: 3.10.0-1160.el7.x86_64

我在服务器上开展性能测试，对大页内存（hugepage）的表现存在疑惑。使用test-tlb工具，运行的Shell脚本如下：

for i in 128k 512k 1M 2M 4M 8M 16M 32M 64M 128M; do echo "$i:"; ./test-tlb -H 4G $i ; ./test-tlb 4G $i ; ./test-tlb -Hr 4G $i ; ./test-tlb -r 4G $i ; done

参数说明：

• -H: 使用大页内存（透明大页或预留大页）
• -r: 随机访问模式，无参数为顺序访问

128k:
 87.24ns (~279.2 cycles)
 98.24ns (~314.4 cycles)
 90.07ns (~288.2 cycles)
108.19ns (~346.2 cycles)
512k:
 87.17ns (~279.0 cycles)
 92.55ns (~296.1 cycles)
 90.51ns (~289.6 cycles)
 95.03ns (~304.1 cycles)
1M:
 88.28ns (~282.5 cycles)
 34.73ns (~111.1 cycles)
 90.76ns (~290.4 cycles)
 36.47ns (~116.7 cycles)
2M:
 91.01ns (~291.2 cycles)
 34.91ns (~111.7 cycles)
 91.56ns (~293.0 cycles)
 35.51ns (~113.6 cycles)
4M:
 90.92ns (~290.9 cycles)
 34.96ns (~111.9 cycles)
 91.62ns (~293.2 cycles)
 35.46ns (~113.5 cycles)
8M:
 90.99ns (~291.2 cycles)
 35.04ns (~112.1 cycles)
 91.55ns (~293.0 cycles)
 35.31ns (~113.0 cycles)
16M:
 77.65ns (~248.5 cycles)
 35.38ns (~113.2 cycles)
 78.23ns (~250.4 cycles)
 35.49ns (~113.6 cycles)
32M:
 20.51ns (~65.6 cycles)
 35.47ns (~113.5 cycles)
 20.61ns (~65.9 cycles)
 35.96ns (~115.1 cycles)
64M:
 21.06ns (~67.4 cycles)
 25.61ns (~81.9 cycles)
 20.66ns (~66.1 cycles)
 23.35ns (~74.7 cycles)
128M:
 21.12ns (~67.6 cycles)
 14.64ns (~46.8 cycles)
 20.69ns (~66.2 cycles)
 14.92ns (~47.7 cycles)

注：每组结果依次对应顺序大页、顺序普通页、随机大页、随机普通页的访问延迟

从1MB步长开始，大页内存的访问延迟反而比普通页更高，且透明大页（THP）和预留大页结果一致。请问这是硬件还是操作系统内核层面的因素导致的？

1. 硬件层面：Xeon E5-2667 v3的TLB特性限制 #

Xeon E5-2667 v3基于Haswell架构，其TLB（翻译后备缓冲器）结构有明确的容量限制：

• L1d TLB：每个核心支持64个4KB页条目、32个2MB页条目、4个1GB页条目
• L2 TLB：每个核心支持1024个4KB页条目、128个2MB/1GB页条目

当测试步长为1MB时，大页模式实际使用的是2MB标准大页（Linux默认大页大小），此时会出现两个关键问题：

• 顺序访问时，1MB步长会频繁跨越2MB大页的边界，每次跨边界都需要重新加载TLB条目，TLB miss概率显著上升；而普通4KB页模式下，1MB步长仅需256个4KB页条目，远低于L1+L2 TLB的总容量，TLB miss极少。
• 只有当步长足够大（如32MB及以上）时，普通页需要的TLB条目数量（32MB/4KB=8192个）远超L2 TLB容量，TLB miss急剧增加；而大页仅需16个2MB条目，完全在TLB容量范围内，此时大页的优势才会显现。

2. 操作系统内核层面：CentOS 7.9大页实现的局限性 #

• 透明大页（THP）的对齐开销：CentOS 7默认THP策略为always，但对于1MB这种非2MB对齐的步长访问，THP会频繁触发大页拆分或回退到普通页的逻辑，引入额外内核开销，拉高延迟。
• 预留大页的严格对齐要求：预留大页必须按2MB边界分配，1MB步长访问会频繁跨越对齐边界，触发更多TLB刷新操作；而普通页无严格对齐要求，访问模式更适配步长。
• 老版本内核的优化不足：3.10.x属于较老的稳定版内核，THP和大页的调度优化远不如5.x+版本，对非标准步长的访问场景，大页的额外开销更明显。

3. 测试工具的行为影响 #

test-tlb的-H参数会尝试分配连续的大页内存，但1MB步长无法匹配大页的整数倍，导致内存访问的局部性被破坏，反而不如普通页的分散分配更适配步长，缓存和TLB利用率下降。

验证建议 #

• 调整测试步长为2MB的整数倍（如2MB、4MB、8MB），再对比大页与普通页的延迟，应能看到大页的性能优势。
• 关闭透明大页，仅使用预留大页，测试对齐后的访问延迟。
• 升级内核至5.x版本，重新测试观察大页表现是否改善。

内容的提问来源于stack exchange，提问作者gugugu