一次开发中，遇到一个问题：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中读数据。
