内存映射内核和用户读写数据不同步

arm-linux-gcc

回复 20# Tinnal



vmalloc还好，因为分配出来的物理内存本来就可能不连续，在这种情况下要想再满足page color几乎是不可能的，
估计内核中也没有谁会把vmalloc的那些物理内存再额外做一份映射

vipt在非线性区域最麻烦的是kmap和kmap_atomic这两个区域，因为这两个区域每个item的虚拟地址是固定死的，要为其做page color是相当麻烦的，
所以内核为了避免麻烦，vipt aliasing data cache时甚至不允许使用high memory




vipt的data cache就是蛋疼，所以如果有硬件解决aliasing的vipt cache用起来就很方便
三星6410是arm1176jzf-s，他的data cache是vipt nonaliasing的，用起来不需要有那么多注意
我以前工作的公司的soc也是arm1176jzf-s的核，不过尼玛data cache是vipt aliasing的，需要比较注意才不会出错

arm-linux-gcc

回复 19# Tinnal


    x86 cache寻址方式出处我忘记是在那里看到的了
powperpc我是在603e手册上看到的

Tinnal

回复 21# arm-linux-gcc

vipt的data cache就是蛋疼，所以如果有硬件解决aliasing的vipt cache用起来就很方便

要体谅一下做硬件的，从硬件就解决aliasing也很烦。呵呵。RISC麻，能软件做的就软件做，只要对性能不会下降，不然又回到CISC上了。我也做过CPU，很多东西要做软件和硬件简折中。

   

wLiu2007

看了这个帖子才了解到有VIVT VIPT PIPT这么些东西；看了些资料，不知道理解是否正确？

VIPT aliasing问题是不是只有在Page Size < Cache Size(指的是单个Way的size)的时候才会出现；因为单个way的cache size和cache line的长度决定了这一个way里面有多少个cache line，进一步决定了tag、index、word各占几个bit；

当page size=4k，那么地址中page offset占用12位，page frame num（PFN）占用20位；如果cache line很多，使的index+word占用bit数超过了12个，那么在通过VA获取index的时候，VA中PFN的后几个比特会当作index的高几个bit；这样会导致下面提到的问题1；
在通过PA获取tag的时候，PA的低几个bit会丢弃，会导致下面提到的问题2；

如果Page Size < Cache Size后，会产生2个问题：
1，如果2个VA映射到同一个PA的话，这个PA可能占用2个不同的cache line，这样就有数据更新不同步的问题；

2，如果2个VA映射到2个不同的PA，映射关系VA1-PA1， VA2-PA2， 访问VA1的时候，有可能取得数据是VA2的数据；因为通过VA1和VA2提取的index是一样的，PA1和PA2的PFN的高几个比特相同，只有最后一个bit不同，但是tag只取高几个bit，所以通过PA1和PA2提取出来的Tag也是一样的；

如果上面理解正确，只要保证每个way的size小于等于4K，然后多弄几个Way，这样即解决了vipt aliasing的问题，整个cache的容量也不会很小，呵呵
不知道多个way，tag需要多路同时比较，硬件复杂度上会增加多少，成本会增加多少

Tinnal

回复 24# wLiu2007

cache和MMU在CPU内部是两个独立的硬件。你太过于强调，他们弄成一个整体了。VIPT等的模式，主要是因为（用软件的概念来说）：cache有两个入参一个是index, 另一个是tag。他们从那去取的问题，从物理地址去取？不是从虚拟地址去去。这跟两个硬件的间接关系相关，但两个硬件内部的处理，就完全不相关了。因为用PAGE_SIZE和cache size/cache line size去做强相关分析是不对的。你的总体出发点就错了。


下面针对你写的内容做一下说明：

1，如果2个VA映射到同一个PA的话，这个PA可能占用2个不同的cache line，这样就有数据更新不同步的问题；

这个理解是对的。这就是cache aliasing的根因。如arm-linux-gcc兄所说，可以由软件按color对齐（目标是让两个虚拟地址

VA中PFN的后几个比特

一样）去解决；或硬件增加相应的电路去保证。

2，如果2个VA映射到2个不同的PA，映射关系VA1-PA1， VA2-PA2， 访问VA1的时候，有可能取得数据是VA2的数据；因为通过VA1和VA2提取的index是一样的，PA1和PA2的PFN的高几个比特相同，只有最后一个bit不同，但是tag只取高几个bit，所以通过PA1和PA2提取出来的Tag也是一样的；

你应该是指如下的情况：

1.     |->page shift                   |->page shift
   
2.     | |->cache line shift           | |->cache line shift
   
3. X001|a|o(虚拟地址）        ->   A000|b|o（物理地址）
   
4.     | |                             | |
   
5. Y001|a|o                   ->   A111|b|o

复制代码

X001a0和Y001a0两个虚拟地址有相同的index：001a和相同的Tag： A，因此同在一个cache line里头。但他们对应的物理地址并不一样。因此如果X001a0先读，发生cache miss，然后再读Y001a0，将cache命中，并把属于A000bo的内容读进来。

这个问题在http://en.wikipedia.org/wiki/CPU_cache的VIPT节里已经有说明：

VIPT requires more tag bits, as the index bits no longer represent the same address.

另外，对于你所于的解决方面。你要清楚组相关cache，一个SET内部是全相关的，而set间是直接映射的。全相关电路需要的比较器数量是直接映射的需要的比较器不是一个级数的。要不然直接全相关好了，都不用来个组相关的了。这个用多级页表来形容你应该会清楚一点。谁想转换一个地址查半天，但如果用一个表，那就表就实在太大、浪费太多的内存了。



   

wLiu2007

回复 25# Tinnal

我将我的问题2用一个图来描述：
假设page size 是4k，one way cahce size=8k，cache line 长度=32B；则index需要8个比特；


图中2个VA1 ！= VA2； PA1 ！= PA2；
第一次访问VA1之后会把PA1的内容放在cache line 0上；
紧接着访问VA2的时候，根据VA2取出index是在line 0上，根据PA2取出来的Tag与cache line 0的tag也是匹配的；于是硬件认为cache命中了；
导致的结果就是访问VA2却错误的取了PA1的内容（正确的应该是取PA2的内容）；

好像这个现象并不是cache alias（alias是指同一个PA映射到2个不同的VA上的），这个现象是2个PA映射到2个不同的VA，page color能否解决这个问题？

Tinnal

回复 26# wLiu2007
page color解决不了这类问题，前面我说得不够清楚？

这个问题硬件会通过

VIPT requires more tag bits, as the index bits no longer represent the same address.

来解决。说白了，针对你的案例，只要Tag增加到4位。那两个物理地址的tag就不一样了。一个为1110， 另外一个为1111。
另外，tag和index是两个参数，而且现在甚至连接到不同的源，不要去强调tag+index+offset一定是32位！

这些wiki里已经说得很清楚，请先认直阅读。

当然，我是也是wiki、google里推导的，如果有什么错误，请arm-linux-gcc兄指正。
   

wLiu2007

回复 27# Tinnal
Tag保存多少个bit是硬件固定好了吧，从这个层面来说，Tag的位数也能影响OS支持的page size最小值；
假设硬件tag就只有19个bit，如果page size是4k的话，图里面举得这个例子就不可避免了；要想解决这个问题，就只能加大page size 到8k了；

Tinnal

回复 22# arm-linux-gcc
让arm-linux-gcc来答吧。


   

枫露清愁

楼上的几位仁兄，真的受教了