Ion内存的带cahce与不带cache问题分享

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

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

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

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

为什么呢？为了加快cpu的访问速度，会把一些变量值加载到寄存器中使用，当修改了该值后，其只更新在寄存器中，而不是在实际的mem中，虽然看似在对某内存地址上进行修改。而问题发生切换时，线程2中看到的相同地址下的值可能是线程1修改前的值。

因为cpu被这个线程使用时，cpu觉得“只有我一个人操作这个内存地址，因此我把这个值备份到更快速的地方(cache/register)来加快访问速度，直到万不得已我才把数据加载到mem中”，因此两个线程看到的同一mem地址下的数据可能不相同。

借此机会，再来引申，说明一下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，如果命中了就不必再去物理磁道上去读数据。

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)的访问。

如何保证内存数据一致性呢？（带cache的一个潜在后果）

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

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