一次HugePage碎片引发的DPDK性能雪崩——深入理解TLB、HugePage、IOMMU与地址转换（上）

一、一次普通的业务扩容性能却突然下降了30%某运营商省级核心交换平台已经稳定运行两年。整个平台采用DPDK构建数据平面承担L3转发、ACL过滤、QoS以及流量统计等功能。系统长期保持稳定吞吐稳定在90Gbps以上CPU保持100%符合PMD Poll Mode特征平均时延约20μs无丢包。某天为了支持新的政企业务研发团队增加了大量ACL规则。整个改动只有两项ACL规则数量从8K增加到64KSession容量由20万提升至100万。代码没有任何修改。只是配置发生变化。版本上线后。监控平台立即报警。交换机吞吐开始持续下降指标升级前升级后吞吐92 Gbps63 GbpsCPU100%100%RX Drop00TX Drop00Cache Miss正常正常NUMA正常正常现场所有人都懵了。CPU没有变化。网卡没有丢包。Cache命中率也没有明显下降。为什么吞吐会下降近三分之一二、第一轮排查是不是ACL变慢了ACL规则从8K ↓ 64K第一反应自然就是ACL查找时间增加。工程师立即运行perf record perf report热点统计函数CPU占比rte_acl_classify()33%Parser18%Session Lookup16%TX Burst17%其它16%与升级前相比ACL只增加了约2%。完全不足以解释30%的吞吐下降。ACL排除。三、第二轮排查是不是Session太大Session从20万 ↓ 100万工程师开始怀疑Hash冲突。继续统计Hash Lookup 平均 78 ns升级前74 ns几乎没有区别。继续观察Session命中率正常。Hash冲突正常。RCU正常。Session不是瓶颈。四、第三轮排查CPU是不是一直在等待继续perf stat统计Instructions Cycles IPC结果指标升级前升级后Cycles基本一致基本一致Instructions↓16%IPC1.811.49CPU一直100%。但是真正执行的指令减少了。说明CPU不是忙于计算。而是在等待。继续观察Backend Stall明显增加。可是Cache Miss却依然正常。会议室再次陷入沉默。CPU在等待。却不是等待Cache。那到底在等什么五、一个几乎没人关注的指标团队继续查看perf stat增加新的事件dTLB-load-misses iTLB-load-misses结果所有人第一次注意到升级前 dTLB-load-misses 3.1M升级后27.8M增加了近九倍。终于真正异常的指标出现了。可是 TLB是什么为什么CPU会因为它下降30%的性能六、CPU访问内存并不是直接访问内存很多开发者都有一个误解。认为CPU访问变量session-far_id流程就是CPU ↓ Memory实际上。现代CPU真正执行的是Virtual Address ↓ TLB ↓ Page Table ↓ Physical Address ↓ Memory也就是说程序里面所有指针全部都是虚拟地址Virtual AddressVACPU并不知道真正的物理地址。必须经过MMUMemory Management Unit。完成地址转换。整个过程。TLB就是第一站。七、TLB到底是什么TLB全称Translation Lookaside Buffer。很多教材把它翻译成快表。实际上更容易理解的是地址转换缓存。CPU每天都在做同一件事例如pkt-data session-teid far-action这些全部都是虚拟地址。如果每一次访问CPU都去查Linux页表整个系统几乎无法工作。因此CPU把最近使用过的地址映射缓存起来。例如VA 0x7f100000 ↓ PA 0x183400000下一次再次访问0x7f100000CPU直接命中TLB。不用查页表。整个过程只需要几个Cycle。八、如果TLB没有命中会发生什么假设TLB里面没有当前地址。CPU只能开始Page Walk。流程Virtual Address ↓ Page Table Level4 ↓ Level3 ↓ Level2 ↓ Level1 ↓ Physical Address整个过程可能需要几十甚至上百个Cycle。如果页表本身不在Cache。CPU还要继续访问Memory。于是一次TLB Miss成本远远超过一次L1 Cache Miss。这也是为什么虽然Cache Miss正常CPU依然等待。因为它等待的是地址翻译。而不是数据。九、为什么ACL扩容会导致TLB Miss暴涨到这里。很多人会产生疑问。ACL增加和TLB有什么关系答案就在于工作集Working Set变大了。升级之前系统访问的数据主要包括mbufSession少量ACL节点。这些数据集中分布在有限数量的HugePage中TLB很容易缓存。升级之后新增大量ACL Trie节点更多Session对象更多统计结构。CPU每处理一个数据包需要访问的虚拟页数量明显增加TLB容量开始不够。于是越来越多的地址转换不得不重新Page Walk。虽然真正访问的数据仍然命中L3 Cache。但是地址翻译已经成为新的瓶颈。这也是为什么Cache Miss没有变化。TLB Miss却增加了九倍。十、为什么DPDK一定要求HugePage现在终于可以回答一个很多人都会问的问题DPDK为什么强制要求HugePage很多文章都会说HugePage减少TLB Miss。但很少解释为什么。假设需要映射1 GB内存。如果使用4KB页。需要1GB ÷ 4KB 262144 页意味着TLB需要记录26万多个地址映射。几乎不可能。如果使用2MB HugePage。只需要1GB ÷ 2MB 512 页如果使用1GB HugePage。整个1GB只需要1 页TLB压力几乎消失。因此。HugePage真正提升性能的原因。并不是内存更快。而是CPU需要维护的地址映射数量大幅减少。未完待续