一次开发中,遇到一个问题:YUV图像(由本地磁盘文件读到ION内存中)缩放时,对于缩放模块的输入源来说,使用带cache的方式要比不带cache的方式速度快数10倍。

为什么会出现这个情况呢?

 

1.在解释这个前,需要有一些基础知识,可以回想一下volatile的用途。

它使用在什么场景下呢?多个线程同时访问一个全局变量,例如线程1和线程2都对同一个内存地址的全局变量进行读/写操作,这时就需要将这个变量声明为volatile。

为什么呢?为了加快cpu的访问速度,会把一些变量值加载到寄存器或缓存中使用,当修改了该值后,其只更新寄存器或缓存的值,而不是在实际的主存(内存)中,虽然看似在对某内存地址上进行修改。

而问题发生线程切换时,线程2中看到的相同地址下的值可能是线程1修改前的值。因为cpu被这个线程使用时,cpu觉得“只有我一个人操作这个内存地址,因此我把这个值备份到更快速的地方(cache/register)

来加快访问速度,直到万不得已我才把数据加载到mem中”,因此两个线程看到的同一mem地址下的数据可能不相同。

总结来说,为了效率,对内存的写入一般会在每一个处理器中缓冲,并在必要时一起flush到主存。

 

2.借此机会,再来引申,说明一下write-through和write-back的概念。

Write-through- Write is done synchronously both to the cache and to the backing store.
Write-back (or Write-behind) – Writing is done only to the cache. A modified cache block is written back to the store, just before it is replaced.
翻译:

Write-through(直写)——写操作同时被更新到cache和后端存储。

Write-back(回写)——写操作仅仅被更新到cache中。只有在这个cache将要被更新前,才将旧数据更新到后端存储。

二者各有优缺点:直写模式下,速度较慢,但数据安全。回写模式下,速度快,但数据不安全(设备断电了!)。

机械硬盘就是一个很好的例子,例如往硬盘写数据时,也是使用Write-back模式,先写到硬盘的cache中,cpu就去干其它事情了,而接下来时间磁盘可能偷偷将cahe中的数据刷新到物理介质中。

从磁盘读数据时,也是先将物理介质上一大块数据加载到cache中,下次访问附近的数据时,先在磁盘cache中看下是否能够hit,如果命中了就不必再去物理磁道上去读数据。

 

3.OK,联想打住,回到最初的问题。

为什么ion内存分带cache和不带cache呢?很多模块(VideoCodec、cam、disp)都需要频繁对mem数据进行更新。

例如h264码流解码后,需要将解码器的output_buf的数据传给(传mem_addr)缩放模块,假如缩放模块进行soft scale down,cpu则去根据一定的算法在mem中抽取像素值。

假如不带cache,那么速度很慢,因为从phy mem上拿数据毕竟慢,但假如带cache(数据也从phy_mem上刷新到cache),则直接从cache中拿数据则很快。

同时,特别需要注意一点,这个cache是属于cpu的,而其他外设不知道有这个cache,因而外设只是在实际phy_mem上进行数据更新;然而cpu对mem的访问,表面上看似对phy_mem的访问,但实际上可能是对其镜像(cache)的访问。

 

4.如何保证内存数据一致性呢?(带cache的一个潜在后果)

当编解码模块写数据了后,cpu去读,则需要调用特定的接口,强制从mem中读数据,而不是从cache中读数据。

当cpu写数据(到cache)了后,编解码模块需要调用特定的接口,将cache中的数据刷新到mem中,编解码模块再从mem中读数据。