您可以捐助,支持我们的公益事业。

1元 10元 50元





认证码:  验证码,看不清楚?请点击刷新验证码 必填



  求知 文章 文库 Lib 视频 iPerson 课程 认证 咨询 工具 讲座 Model Center   Code  
会员   
   
 
     
   
 订阅
  捐助
深入理解CPU cache:组织、一致性(同步)、编程
作者 :宋宝华
  345  次浏览      3 次
 2023-1-31
 
编辑推荐:
本文主要介绍了CPU cache:组织、一致性(同步)、编程。希望对您的学习有所帮助。
本文来自微信公众号Linux云计算网络,由火龙果软件Linda编辑、推荐。

CACHE 基础

对cache的掌握,对于Linux工程师(其他的非Linux工程师也一样)写出高效能代码,以及优化Linux系统的性能是至关重要的。简单来说,cache快,内存慢,硬盘更慢。在一个典型的现代CPU中比较接近改进的哈佛结构,cache的排布大概是这样的:

L1速度>  L2速度> L3速度> RAM
L1容量<  L2容量< L3容量< RAM

现代CPU,通常L1 cache的指令和数据是分离的。

这样可以实现2条高速公路并行访问,CPU可以同时load指令和数据。当然,cache也不一定是一个core独享,现代很多CPU的典型分布是这样的,比如多个core共享一个L3。

比如这台的Linux里面运行 lstopo 命令:

人们也常常称呼L2cache为 MLC (MiddleLevel Cache), L3cache为 LLC(Last LevelCache)。

这些Cache究竟有多块呢?

我们来看看Intel的数据,具体配置:
Intel i7-4770 (Haswell), 3.4 GHz (Turbo Boostoff), 22 nm. RAM: 32 GB (PC3-12800 cl11 cr2)

访问延迟:

L1 Data Cache Latency 
4 cycles for simple 
access
 via pointer
L1 Data Cache Latency 
5 cycles for access with 
complex address calculation 
(size_t n, *p; n = p[n]).
L2 Cache Latency = 12 cycles
L3 Cache Latency = 36 cycles (
3.4
 GHz i7-4770)
L3 Cache Latency = 43 cycles 
(1.6 GHz E5-2603 v3)
L3 Cache Latency = 58 cycles 
(core9) - 66 cycles (core5) (
3.6
 GHz E5-2699 v3 - 18 cores)
RAM Latency = 36 cycles + 57 ns 
(3.4 GHz i7-4770)
RAM Latency = 62 cycles + 100 
ns (3.6 GHz E5-2699 v3 dual)

由此我们可以知道,我们应该尽可能追求cache的命中率高,以避免延迟, 最好是低级cache的命中率越高越好。

CACHE 的组织

SET、WAY、TAG、INDEX

现代的cache基本按照这个模式来组织:SET、WAY、TAG、INDEX

,这几个概念是理解Cache的关键。随便打开一个数据手册,就可以看到这样的字眼:

但是它的执行时间,则远远不到后者的8倍:

16KB 的cache是 4way 的话,每个set包括 4*64B ,则整个cache分为 16KB/64B/4 = 64set

,也即2的6次方。当CPU从cache里面读数据的时候,它会用地址位的BIT6-BIT11来寻址set,BIT0-BIT5是cacheline内的offset。

比如CPU访问地址

0 000000 XXXXXX

或者

1 000000 XXXXXX

或者

YYYY 000000 XXXXXX

 

由于它们红色的6位都相同,所以他们全部都会找到第0个set的cacheline。第0个set里面有4个way,之后硬件会用地址的高位如0,1,YYYY作为tag,去检索这4个way的tag是否与地址的高位相同,而且cacheline是否有效,如果tag匹配且cacheline有效,则cache命中。

所以地址YYYYYY 000000XXXXXX全部都是找第0个set,YYYYYY000001XXXXXX全部都是找第1个set,YYYYYY111111XXXXXX全部都是找第63个set。每个set中的4个way,都有可能命中。

中间红色的位就是INDEX,前面YYYY这些位就是TAG。

具体的实现可以是用虚拟地址或者物理地址的相应位做TAG或者INDEX。

如果用虚拟地址做TAG,我们叫VT;

如果用物理地址做TAG,我们叫PT;

如果用虚拟地址做INDEX,我们叫VI;

如果用物理地址做INDEX,我们叫PI。

工程中碰到的cache可能有这么些组合:VIVT、VIPT、PIPT。

VIVT、VIPT、PIPT

具体的实现可以是用虚拟地址或者物理地址的相应位做TAG或者INDEX。

如果用虚拟地址做TAG,我们叫VT;

如果用物理地址做TAG,我们叫PT;

如果用虚拟地址做INDEX,我们叫VI;

如果用物理地址做INDEX,我们叫PI。

VIVT的硬件实现开销最低,但是软件维护成本高;PIPT的硬件实现开销最高,但是软件维护成本最低;VIPT介于二者之间,但是有些硬件是VIPT,但是behave

as PIPT,这样对软件而言,维护成本与PIPT一样。

在VIVT的情况下,CPU发出的虚拟地址,不需要经过MMU的转化,直接就可以去查cache。

而在VIPT和PIPT的场景下,都涉及到虚拟地址转换为物理地址后,再去比对cache的过程。VIPT如下:

PIPT如下:

从图上看起来,VIVT的硬件实现效率很高,不需要经过MMU就可以去查cache了。不过,对软件来说,这是个灾难。因为VIVT有严重的歧义和别名问题。

歧义:一个虚拟地址先后指向两个(或者多个)物理地址

别名:两个(或者多个)虚拟地址同时指向一个物理地址

Cache别名问题

这里我们重点看别名问题。比如2个虚拟地址对应同一个物理地址,基于VIVT的逻辑,无论是INDEX还是TAG,2个虚拟地址都是可能不一样的(尽管他们的物理地址一样,但是物理地址在cache比对中完全不掺和),这样它们完全可能在2个cacheline同时命中。

由于2个虚拟地址指向1个物理地址,这样CPU写过第一个虚拟地址后,写入cacheline1。CPU读第2个虚拟地址,读到的是过时的cacheline2,这样就出现了不一致。所以,为了避免这种情况,软件必须写完虚拟地址1后,对虚拟地址1对应的cache执行clean,对虚拟地址2对应的cache执行invalidate。

而PIPT完全没有这样的问题,因为无论多少虚拟地址对应一个物理地址,由于物理地址一样,我们是基于物理地址去寻找和比对cache的,所以不可能出现这种别名问题。

那么VIPT有没有可能出现别名呢?答案是有可能,也有可能不能。 如果VI恰好对于PI,就不可能,这个时候,VIPT对软件而言就是PIPT了:

VI=PI
PT=PT

那么什么时候VI会等于PI呢?这个时候我们来回忆下虚拟地址往物理地址的转换过程,它是以页为单位的。假设一页是4K,那么地址的低12位虚拟地址和物理地址是完全一样的。回忆我们前面的地址:

YYYYY000000XXXXXX

其中红色的000000是INDEX。在我们的例子中,红色的6位和后面的XXXXXX(cache内部偏移)加起来正好12位,所以这个000000经过虚实转换后,其实还是000000的,这个时候

VI=PI ,VIPT没有别名问题。

我们原先假设的cache是:16KB大小的cache,假设是4路组相联,cacheline的长度是 64字节

,这样我们正好需要红色的6位来作为INDEX。但是如果我们把cache的大小增加为32KB,这样我们需要

32KB/4/64B=128=2^7,也即7位来做INDEX。

YYYY0000000XXXXXX

这样VI就可能不等于PI了,因为红色的最高位超过了2^12的范围,完全可能出现如下2个虚拟地址,指向同一个物理地址:

这样就出现了别名问题,

我们在工程里,可能可以通过一些办法避免这种别名问题,比如软件在建立虚实转换的时候,把虚实转换往2^13而不是2^12对齐,让物理地址的低13位而不是低12位与物理地址相同,这样强行绕开别名问题,下图中,2个虚拟地址指向了同一个物理地址,但是它们的INDEX是相同的,这样VI=PI,就绕开了别名问题。这通常是PAGE

COLOURING技术中的一种技巧。

如果这种PAGE

COLOURING的限制对软件仍然不可接受,而我们又想享受VIPT的INDEX不需要经过MMU虚实转换的快捷?有没有什么硬件技术来解决VIPT别名问题呢?确实是存在的,现代CPU很多都是把L1

CACHE做成VIPT,但是表现地(behave as)像PIPT。这是怎么做到的呢?

这要求VIPT的cache,硬件上具备alias detection的能力。比如,硬件知道YYYY 0000000 XXXXXX既有可能出现在第

0000000 ,又可能出现在 1000000

这2个set,然后硬件自动去比对这2个set里面是否出现映射到相同物理地址的cacheline,并从硬件上解决好别名同步,那么软件就完全不用操心了。

下面我们记住一个简单的规则:

对于VIPT,如果cache的size除以WAY数,小于等于1个page的大小,则天然VI=PI,无别名问题;

对于VIPT,如果cache的size除以WAY数,大于1个page的大小,则天然VI≠PI,有别名问题;这个时候又分成2种情况:

硬件不具备alias detection能力,软件需要pagecolouring;

硬件具备alias detection能力,软件把cache当成PIPT用。

比如cache大小64KB,4WAY,PAGE SIZE是4K,显然有别名问题;这个时候,如果cache改为16WAY,或者PAGE

SIZE改为16K,不再有别名问题。为什么?感觉小学数学知识也能算得清��

CACHE 的一致性

Cache的一致性有这么几个层面

1.一个CPU的icache和dcache的同步问题

2.多个CPU各自的cache同步问题

3.CPU与设备(其实也可能是个异构处理器,不过在Linux运行的CPU眼里,都是设备,都是 DMA )的cache同步问题

cache中的映射

1. 直接映射

一个内存地址能被映射到的Cache line是固定的。就如每个人的停车位是固定分配好的,可以直接找到。缺点是:因为人多车位少,很可能几个人争用同一个车位,导致Cache淘汰换出频繁,需要频繁的从主存读取数据到Cache,这个代价也较高。

2. 全相联映射

主存中的一个地址可被映射进任意cache line,问题是:当寻找一个地址是否已经被cache时,需要遍历每一个cache line来寻找,这个代价很高。就像停车位可以大家随便停一样,停的时候简单,找车的时候需要一个一个停车位的找了。

主存中任何一块都可以映射到Cache中的任何一块位置上。

全相联映射方式比较灵活,主存的各块可以映射到Cache的任一块中,Cache的利用率高,块冲突概率低,只要淘汰Cache中的某一块,即可调入主存的任一块。但是,由于Cache比较电路的设计和实现比较困难,这种方式只适合于小容量Cache采用。

3. 组相联映射

组相联映射实际上是直接映射和全相联映射的折中方案,其组织结构如图(3)所示。

主存和Cache都分组,主存中一个组内的块数与Cache中的分组数相同,组间采用直接映射,组内采用全相联映射。也就是说,将Cache分成2^u组,每组包含2^v块,主存块存放到哪个组是固定的,至于存到该组哪一块则是灵活的。即主存的某块只能映射到Cache的特定组中的任意一块。主存的某块b与Cache的组k之间满足以下关系:k=b%(2^u).

icache、dcache同步 - 指令流( icache )和数据流( dcache )

先看一下 ICACHE 和 DCACHE 同步问题。由于程序的运行而言, 指令流的都流过icache ,而指令中涉及到的数据流经过dcache 。所以对于自修改的代码(Self-Modifying Code)而言,比如我们修改了内存p这个位置的代码(典型多见于JIT

compiler),这个时候我们是通过store的方式去写的p,所以新的指令会进入dcache。但是我们接下来去执行p位置的指令的时候,icache里面可能命中的是修改之前的指令。

所以这个时候软件需要把dcache的东西clean出去,然后让icache invalidate,这个开销显然还是比较大的。

但是,比如ARM64的N1处理器,它支持硬件的icache同步,详见文档:The Arm Neoverse N1 Platform: Building Blocks for the Next-Gen Cloud-to-Edge Infrastructure SoC

特别注意画红色的几行。软件维护的成本实际很高,还涉及到icache的invalidation向所有核广播的动作。

接下来的一个问题就是多个核之间的cache同步。下面是一个简化版的处理器,CPU_A和B共享了一个L3,CPU_C和CPU_D共享了一个L3。实际的硬件架构由于涉及到NUMA,会比这个更加复杂,但是这个图反映层级关系是足够了。

比如CPU_A读了一个地址p的变量?CPU_B、C、D又读,难道B,C,D又必须从RAM里面经过L3,L2,L1再读一遍吗?这个显然是没有必要的,在硬件上,cache的snooping控制单元,可以协助直接把CPU_A的p地址cache拷贝到CPU_B、C和D的cache

这样A-B-C-D都得到了相同的p地址的棕色小球。

假设CPU B这个时候,把棕色小球写成红色,而其他CPU里面还是棕色,这样就会不一致了:

这个时候怎么办?这里面显然需要一个 协议,典型的多核cache同步协议有MESI和MOESI。MOESI相对MESI有些细微的差异,不影响对全局的理解。下面我们重点看MESI协议。

MESI 协议

MESI协议定义了4种状态:

M(Modified) :

当前cache的内容有效,数据已被修改而且与内存中的数据不一致,数据只在当前cache里存在;类似RAM里面是棕色球,B里面是红色球(CACHE与RAM不一致),A、C、D都没有球。

E(Exclusive 独有的 )

:当前cache的内容有效,数据与内存中的数据一致,数据只在当前cache里存在;类似RAM里面是棕色球,B里面是棕色球(RAM和CACHE一致),A、C、D都没有球。

S(Shared) :当前cache的内容有效,数据与内存中的数据一致,数据在多个cache里存在。类似如下图,在CPU A-B-C里面cache的棕色球都与RAM一致。

I(Invalid) :当前cache无效。前面三幅图里面cache没有球的那些都是属于这个情况。

然后它有个状态机

这个状态机比较难记,死记硬背是记不住的,也没必要记,它讲的cache原先的状态,经过一个硬件在本cache或者其他cache的读写操作后,各个cache的状态会如何变迁。所以,硬件上不仅仅是监控本CPU的cache读写行为,还会监控其他CPU的。只需要记住一点:这个状态机是为了保证多核之间cache的一致性,比如一个干净的数据,可以在

多个CPU的cache share ,这个没有一致性问题;但是,假设其中一个CPU写过了,比如A-B-C本来是这样:

然后B被写过了:

这样A、C的cache实际是过时的数据,这是不允许的。这个时候,硬件会自动把A、C的cache

invalidate掉,不需要软件的干预,A、C其实变地相当于不命中这个球了:

这个时候,你可能会继续问,如果C要读这个球呢?它目前的状态在B里面是modified的,而且与RAM不一致,这个时候,硬件会把红球clean,然后B、C、RAM变地一致,B、C的状态都变化为S(Shared):

这一系列的动作虽然由硬件完成,但是对软件而言不是免费的,因为它耗费了时间。如果编程的时候不注意,引起了硬件的大量cache同步行为,则程序的效率可能会急剧下降。

为了让大家直观感受到这个cache同步的开销,下面我们写一个程序,这个程序有2个线程,一个写变量,一个读变量:

这个程序里,x和y都是cacheline对齐的,这个程序的thread1的写,会不停地与thread2的读,进行cache同步。

它的执行时间为:

$ time ./a.out 
real  0m3.614s
user  0m7.021s
sys  0m0.004s

 

它在2个CPU上的userspace共运行了7.021秒,累计这个程序从开始到结束的对应真实世界的时间是3.614秒(就是从命令开始到命令结束的时间)。

如果我们把程序改一句话,把thread2里面的c = x改为c =

y,这样2个线程在2个CPU运行的时候,读写的是不同的cacheline,就没有这个硬件的cache同步开销了:

它的运行时间:

$ time ./b.out 
real  0m1.820s
user  0m3.606s
sys  0m0.008s

 

现在只需要1.8秒,几乎减小了一半。

感觉前面那个a.out,双核的帮助甚至都不大。如果我们改为单核跑呢?

$ time taskset -c 0 ./a.out 
real  0m3.299s
user  0m3.297s
sys  0m0.000s

 

它单核跑,居然只需要3.299秒跑完,而双核跑,需要3.614s跑完。单核跑完这个程序,甚至比双核还快,有没有惊掉下巴?!!!因为单核里面没有cache同步的开销。

下一个cache同步的重大问题,就是设备与CPU之间。如果设备感知不到CPU的cache的话(下图中的红色数据流向不经过cache),这样,做DMA前后,CPU就需要进行相关的cacheclean和invalidate的动作,软件的开销会比较大。

这些软件的动作,若我们在Linux编程的时候,使用的是 streaming DMA APIs 的话,都会被类似这样的API自动搞定:

dma_map_single()
dma_unmap_single()
dma_sync_single_for_cpu()
dma_sync_single_for_device()
dma_sync_sg_for_cpu()
dma_sync_sg_for_device()

 

如果是使用的 dma_alloc_coherent ()API呢,则设备和CPU之间的buffer是cache一致的,不需要每次DMA进行同步。对于不支持硬件cache一致性的设备而言,很可能dma_alloc_coherent()会把CPU对那段DMA

buffer的访问设置为uncachable的。

这些API把底层的硬件差异封装掉了,如果硬件不支持CPU和设备的cache同步的话,延时还是比较大的。那么,对于底层硬件而言,更好的实现方式,应该仍然是硬件帮我们来搞定。比如我们需要修改总线协议,延伸红线的触角:

当设备访问RAM的时候,可以去snoop CPU的cache:

如果做内存到外设的DMA,则直接从CPU的cache取modified的数据;

如果做外设到内存的DMA,则直接把CPU的cache invalidate掉。

这样,就实现硬件意义上的cache同步。当然,硬件的cache同步,还有一些其他方法,原理上是类似的。注意,这种同步仍然不是免费的,它仍然会消耗bus

cycles的。实际上,cache的同步开销还与距离相关,可以说距离越远,同步开销越大,比如下图中A、B的同步开销比A、C小。

对于一个NUMA服务器而言,跨NUMA的cache同步开销显然是要比NUMA内的同步开销大。

意识到 CACHE 的编程

通过上一节的代码,读者应该意识到了cache的问题不处理好,程序的运行性能会急剧下降。所以意识到cache的编程,对程序员是至关重要的。

   
345 次浏览       3
相关文章

企业架构、TOGAF与ArchiMate概览
架构师之路-如何做好业务建模?
大型网站电商网站架构案例和技术架构的示例
完整的Archimate视点指南(包括示例)
相关文档

数据中台技术架构方法论与实践
适用ArchiMate、EA 和 iSpace进行企业架构建模
Zachman企业架构框架简介
企业架构让SOA落地
相关课程

云平台与微服务架构设计
中台战略、中台建设与数字商业
亿级用户高并发、高可用系统架构
高可用分布式架构设计与实践

最新活动计划
PowerBI 数据分析与可视化 2-15[北京]
MBSE(基于模型的系统工程) 2-23[北京]
图数据库与知识图谱 2-25[北京]
人工智能+python+大数据 2-27[北京]
自动驾驶系统软件架构设计 3-9[北京]
基于SysML和EA系统分析设计 3-27[北京]
 
最新文章
架构设计-谈谈架构
实现SaaS(软件及服务)架构三大技术挑战
到底什么是数据中台?
响应式架构简介
业务架构、应用架构与云基础架构
最新课程
软件架构设计方法、案例与实践
从大型电商架构演进看互联网高可用架构设计
大型互联网高可用架构设计实践
企业架构师 (TOGAF官方认证)
嵌入式软件架构设计—高级实践
更多...   
成功案例
某新能源电力企业 软件架构设计方法、案例与实践
中航工业某研究所 嵌入式软件开发指南
某轨道交通行业 嵌入式软件高级设计实践
北京 航天科工某子公司 软件测试架构师
北京某领先数字地图 架构师(设计案例)
更多...