高性能编程:三级缓存(LLC)访问优化

栏目: IT技术 · 发布时间: 4年前

内容简介:AMD 服务器,多线程应用绑核,选取不同的 CPU 核,性能差距可达50%。

高性能编程:三级缓存(LLC)访问优化

作者: ciuwaalu,腾讯 TEG 后台开发工程师

AMD 服务器,多线程应用绑核,选取不同的 CPU 核,性能差距可达50%。

最近有幸因项目拿到一台 AMD EPYC 系列 测试服务器,发现了一些奇怪的现象。

这台测试服务器拥有双路 AMD EPYC  7552  处理器,属于第二代 Rome(Zen2)架构,单路 48 个物理核,双路总计 192 个逻辑核(线程),有两个 NUMA 节点。

为了进行测试,预先编写了一个简单的多线程程序:

  1. 两个线程,分别为生产者、消费者,模拟 route-worker 模型;

  2. 三个线程,分别为生产者、转发者、消费者,模拟 pipeline 模型。

线程间采用无锁队列通信。生产者依次写入 1 ~100000000,消费者取出数字求和。线程每次写入或读取队列数据后执行一些无意义循环用于消耗时间,模拟业务逻辑。

所有线程分别绑核,避免线程迁移导致 Cache 抖动,且绑定的核心属于同一个 CPU。所有队列均在这个 CPU 的本地内存上进行分配,避免跨 NUMA 的远程内存访问。

奇怪的现象

测试发现,线程绑到不同的核上,有显著的性能差异:

高性能编程:三级缓存(LLC)访问优化
高性能编程:三级缓存(LLC)访问优化

绑核说明:

  1. 核 #4 #5 #6 #8 #12 #100 均为同一个 CPU,不存在跨 NUMA 访问内存的情况;

  2. 核 #4 #100 是一对 SMT 核心,即同一个物理核虚拟出来的两个逻辑核;

  3. 黄条涉及的核 #48 属于另一个 CPU,存在跨 NUMA 访问内存的情况,仅供对比。

测试结果反映了一个很奇怪的现象:线程绑核,在同一个 NUMA 选取不同的核心,性能差距竟然达到 50%(route-worker 模型 #4#5 vs #4#8)甚至 140%(pipeline 模型 #4#5#6 vs #4#8#12)。

这究竟是为什么呢?

复杂的内存层次模型

这要从内存层次说起。通常,根据延迟时间从小到大,内存层次可以划分为:(1)L1,一级缓存;(2)L2,二级缓存;(3)L3,又叫 LLC,三级缓存;(4)内存。

在具体实现上,传统的 Intel 至强系列模型比较简单:

  • 每个物理核虚拟出两个逻辑核(TR1/TR2,TR3/TR4)

  • 每个物理核独有 L1 和 L2

  • 所有物理核共享 L3

高性能编程:三级缓存(LLC)访问优化

这就解释了一些高性能程序开发的优化策略:

  • 避免跨 NUMA 的远程内存访问,除了降低访问延迟,对 L3 也更友好

  • 将线程绑核,避免 Cache 抖动,具体是避免 L1 和 L2 的抖动

  • 共享 L3 的存在是透明的,软件上不关心,也无法关心

这一切,在 AMD 的体系结构中发生了变化。

AMD 于 2017 年发布了 Zen 架构,其中一个重要的设计原则是:一块 CPU 由多个 CCX(CPU Complex)堆叠而成。那么,CCX 是什么呢?简单来说,CCX 实际上就是 4 个物理核(8 个逻辑核)+ L3。CCX 通过 IF 总线与 IO Die 连接(Rome),实现 CCX 间互通以及与内存、IO 的通信。

高性能编程:三级缓存(LLC)访问优化

图片来源: https://frankdenneman.nl/2019/10/14/amd-epyc-naples-vs-rome-and-vsphere-cpu-scheduler-updates/

所以,AMD EPYC 的内存模型就和传统模型有了很大区别:L3 并不由所有物理核共享,而是由同一个 CCX 内的 4 个物理核共享。与 NUMA 引入的“远程内存”概念类似,CCX 引入了“远程 L3”的概念。

高性能编程:三级缓存(LLC)访问优化

网上 找到一个访问延迟表,供参考:

事件 延迟
一个 CPU 周期(2.3GHz 主频) 0.4 ns
访问 L1 1.6 ns
访问 L2 4.8 ns
访问 L3 15.2 ns
访问远程 L3 63 ns
访问本地内存 75 ns
访问远程内存 130 ns

结论与优化建议

结论是,在 AMD 服务器下,如果要获得更高的性能,要针对 L3 进行优化,方法为: 把一组任务(线程、进程)绑定到同一个 CCX 下的核心。

那怎样才能知道哪些核心是同一个 CCX 呢?可以使用 hwloc-ls 命令:

高性能编程:三级缓存(LLC)访问优化

可以看出:#0 #96 #1 #97 #2 #98 #3 #99 是 4 个物理核 8 个逻辑核,它们共享了 16 MB 的 L3,所以这几个核属于同一个 CCX。

因此,绑核的时候,可以绑 #0 #1 #2 #3 #96 #97 #98 #99,又或者 #4 #5 #6 #7 #100 #101 #102 #103,以此类推。

文章开头的测试结果就很好解释了:#4 #5 #6 是同一个 CCX,因为它们共享 L3,每次读写队列其实都是读写 L3,所以性能高;#4 #8 #12 分属 3 个不同的 CCX,每次写队列,都会使得其它 CCX 的 L3 数据失效,导致读队列时必须要从内存中读取,所以性能差。

最后,可以通过:

perf stat -e r510143,r510243,r510843,r511043,r514043 ./xxx 查看 L3 的访问情况,PMC Code 来自 AMD的官方文档

高性能编程:三级缓存(LLC)访问优化
高性能编程:三级缓存(LLC)访问优化
高性能编程:三级缓存(LLC)访问优化

可以看到绑核 #4 #8 读取内存次数几乎是绑核 #4 #5 的 3 倍。

高性能编程:三级缓存(LLC)访问优化


以上就是本文的全部内容,希望本文的内容对大家的学习或者工作能带来一定的帮助,也希望大家多多支持 码农网

查看所有标签

猜你喜欢:

本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们

数据之巅

数据之巅

涂子沛 / 中信出版社 / 2014-5-1 / 65.00元

《数据之巅:大数据革命,历史、现实与未来》从美国建国之基讲起,通过阐述初数时代、内战时代、镀金时代、进步时代、抽样时代、大数据时代的特征,系统梳理了美国数据文化的形成,阐述了其数据治国之道,论述了中国数据文化的薄弱之处,展望了未来数据世界的远景。 “尊重事实,用数据说话”,“推崇知识和理性,用数据创新”,作者不仅意在传承黄仁宇“数目字”管理的薪火,还试图把数据这个科技符号在中国转变为文化符号......一起来看看 《数据之巅》 这本书的介绍吧!

在线进制转换器
在线进制转换器

各进制数互转换器

图片转BASE64编码
图片转BASE64编码

在线图片转Base64编码工具

Base64 编码/解码
Base64 编码/解码

Base64 编码/解码