iCache歧义和别名是怎么产生的？dentry与inode的定义是什么？

iCache歧义和别名

只要是Cache，就不能不提歧义和别名的问题。歧义问题一直是软件最难维护的，所以现在的硬件设计一般都采用物理地址作为tag。这就避免了歧义问题。别名问题是否存在呢？在之前的文章中，我们知道VIPT的cache是可能存在别名的情况。但是针对iCache的特殊情况(readonly)，又会产生什么特殊的结果呢？其实我们之所以需要考虑别名问题，就是因为需要我们维护别名之间的一致性。因为可能在不同的cacheline看到不同的结果。那么iCache会存在别名，但是不是问题。因为iCache是只读的，所以即使两个cacheline缓存一个物理地址上的指令，也不存在问题。因为他的值永远是一致的，没有修改的机会。既然选用VIPT iCache即不存在歧义问题，别名也不是问题。那么我们是不是就不用操心了呢？并不是，我们最后需要考虑的问题是iCache和dCache之间的一致性问题。

dentry与inode

（可参照理解为ext2 inode）

inode对应于物理磁盘上的具体对象，

dentry是一个内存实体，其中的d_inode成员指向对应的inode。

也就是说，一个inode可以在运行的时候链接多个dentry，而d_count记录了这个链接的数量。

按照d_count的值，dentry分为以下四种状态：

0、空闲状态：处于该状态的目录项对象不包括有效信息，且没有被VFS使用。

1、未使用（unused）状态：该dentry对象的引用计数d_count的值为0，但其d_inode指针仍然指向相关的的索引节点。该目录项仍然包含有效的信息，只是当前没有人引用他。这种dentry对象在回收内存时可能会被释放。

2、正在使用（inuse）状态：处于该状态下的dentry对象的引用计数d_count大于0，且其d_inode指向相关的inode对象。这种dentry对象不能被释放。

3、负（negative）状态：与目录项相关的inode对象不复存在（相应的磁盘索引节点可能已经被删除），dentry对象的d_inode指针为NULL。但这种dentry对象仍然保存在dcache中，以便后续对同一文件名的查找能够快速完成。这种dentry对象在回收内存时将首先被释放。