- 论坛徽章:
- 4
|
他说的flush_dcache_page是指的filemap.c，pagefault.c等文件里经常调用的那个函数。
这个函数涉及的方面比较多，触及了体系结构的很多东西。
一般应用此函数的场景为： 发生缺页异常, kernel找到需要映射的page，然后映射到pte中。
但是这中间存在几个晦涩的问题：
1) kernel是否写过这个page？ 如果写过的话，如何保证kernel写此page的操作已经完成，然后才修改的pte？这里需要一个诸如ARM的dmb指令之类的，起一个内存屏障作用的指令。
2) 如果1)解决了，第二个问题是虽然kernel写此page的操作已经完成，但是是写到了cache中，如何使user space的程序能看到cache里的最新内容。
a) PIPT及non-alias VIPT，不需任何操作
b) alias VIPT，在执行mmap时，已经使虚拟地址前20bit相对于最大alias数的模，等于page->index相对于最大alias数的模。这样此page在user space的所有映射，都使用同一个alias，另一个alias是kernel态的映射。这时需要clean & invalidate本page在kernel态的alias
c) VIVT，通过objrmap，将page对应的所有在user态的映射都设置为non-cacheable。
3) 如果2)解决了，那么现在要设置pte。 可能是新增一个pte，也可能是修改pte。如果是修改的话，现在要invalidate TLB。
4) 现在3)解决了，下一个面临的问题是“pte映射的是否代码段”？如果是的话，在某些CPU中，需要刷新BTB，以防止反复的预测出错误分支。
5) 现在看起来事情干完了，但是还有一个问题，我们操作pte的本质是修改了用户程序的数据或者代码。那么CPU的pipeline中，是否还有旧的数据或者代码？
一是超标量的处理器中，reservation station及reorder buffer中，会存有旧的指令
二是处理器读写内存虽然有的顺序有的乱序，但是load/store unit中，(基地址+偏移)-->虚拟地址-->TLB-->物理地址，这个计算目的地址的过程是乱序完成的。 而且即使计算出来要操作的物理地址，也不见得马上提交这个读写操作，因为CPU要遵循某种内存读写模型，以及检测output dependency,anti dependency..... 那么，当我们通过设置pte，修改了程序的数据时，是否会影响到“(基地址+偏移)-->虚拟地址-->TLB-->物理地址”这个计算？答案是肯定的。修改数据后，可能会影响间接寻址；修改了pte及TLB后，会影响虚拟与物理的转换。那么这时，load/store unit中，还没有提交的读写指令，其目的地址很可能是错误的。
三是CPU这年头都有speculative load buffer以完成预读，它和load store unit是一体的，比cache更接近CPU。当修改了程序的数据后，speculative load buffer中很可能有旧的数据。
这几个问题，在ARM中统一通过isb这条指令来解决，其完成的是令CPU roll-back，作废pipeline里的很多内容。和发生中断时，CPU要做的事差不多。 |
|
免费注册
发表于 2011-10-13 14:53
