超标量处理器设计笔记（7） Cache同义重名问题、同名问题，VIPT PIPT VIVT 介绍和对比
Cache设计
Cache 的设计
同义问题 （重名问题）
问题描述
定义：不同名字对应相同的物理位置
重名问题导致虚拟 cache 存在下面问题
- 浪费宝贵的 cache 空间
- 执行 store 指令，写到 cache 时，需要将同一 pa 对应的所有 va 同时修改
如图下，VA1 修改后，VA2 也需要修改
问题原因
什么时候会导致同名问题
对于 4KB 的页，
- 小于 4KB 的 cache，其访问地址不会大于 12 位
- 同一 PA 对应的 VA 一定相同
- 大于 4KB 的 cache，其访问地址大于 12 位时
- Va[11:0] 相同, 但是VPN 不同，但是 PFN 相同，页面偏移也相同
- 如下图，8KB 的 cache，导致[12]只用于访问 cache 行 ？还是也会参与到 TLB 之中呢？
问题案例
使用 bank 来解决重名问题
Cache 中数据部分和 Tag 部分都采用上述 bank 结构
读写过程如下
- 读取 Cache 时，va[11:0]同时访问 bank0/1，根据 TLB 翻译出的 PA[12] 进行选择，PA 与 tag 内的 PA 进行比对
- 写 Cache 时，只有指令 retire 时才会写入到 cache 中，可以根据 pa[12]判断写入哪个 bank 中
这样确实可以增大 cache 的容量
#问题
va[12] == pa[12] 一定等于？会不会干涉到 va 转换 pa？
同名问题
定义
相同名字对应不同的物理地址
原因
当一个进程切换到另外进程时，新进程使用 va 来访问虚拟 cache 时（虚拟地址作为 cache 的 tag 部分），则会出现错误
解决方式
最简单的方式是将虚拟 Cache 所有内容置为无效，对于 TLB 也是如此。
所以带入 PID(process ID)，ASID (address Space IDentifier)，每个进程都有一个 4GB 的虚拟存储区域。
8 位 ASID 则有 2^8=256 个虚拟存储器，一共有 256 * 4GB=1024GB 虚拟地址空间
Global 位：表示所有进程共享的页，不需要理会 ASID 的值
查找方式如下
该方式需要多一次物理内存的查找，造成 TLB 缺失时间增长。
所以第一级 PT 会用 PTR 寄存器来保存
还有一个寄存器来保存当前进程的 ASID 值
TLB 的内容是：ASID + VA
当 ASID PT 用完时，会剔除不常用的 asid，将其在 TLB 的内容里清空
由于新进程的进来会覆盖旧的 PTR 寄存器，为了恢复进程，将 PTR 存储在物理内存中
#问题 虚拟 cache 和物理cache 区别（访问 cache 的是用虚拟地址还是物理地址）AMD 案例是什么 cache？ 虚拟地址
对 cache 进行控制
特殊情况
- DMA 将物理内存的数据搬运到其他地方，最新数据还在 D-cache 中，需要将 D-cache 中的 dirty=1 的数据写回到物理内存里
- DMA 从外界搬数据到物理内存的地址上，地址在 D-cache 缓存，需要将 D-cache 中地址的内容置于无效
- Page fault 页迁移时，该页存在 D-cache 中，需要将 D-cache 写回到物理内存中，再写回到硬盘里
- 处理器进行自修改指令，使 i-cache 所有内容无效，新的指令作为数据写入到 D-cache 中，再写入到物理内存中，最后送入到 I-cache 中。
需要对 cache 进行操作，clean 是将 cache 内容也到物理内存中
- 使得 I-cache 所有/某个 cache line 置为无效
- 使得 D-cache 所有/某个 cache line 进行 clean
- 使得 D-cache 所有/某个 cache line 进行 clean，并且置为无效
寻址 cache line 的方式
- Set/way 信息定位
- 地址
- Index 找到 Cache 中的某个 set
- Tag 从不同 way 选出匹配的 cache line
- Cache 物理地址作为 Tag，还需要将虚拟地址转化为物理地址
ARM 风格的 cache 管理
通过 MRC 和 MCR 指令，修改寄存器
MRC{<cond>} <coproc>, <Opl>, <Rt>, <CRn>, <CRm>{, <0p2>}
MCR{<cond>} <coproc>, <Op1>, <Rt>, <CRn>, <CRm>{, <0p2>}
MIPS 风格的 cache 管理
EA = GPR[base] + offset
将 TLB 和 Cache 放在流水线
PIPT
串行 TLB 和 Cache 访问
对于 I-cache 来说，新增流水线，增加惩罚
对于 D-cache 来说，增加流水线，造成 load 的延迟变大（影响其他指令唤醒）
通常用于： L2 Cahce 中
VIPT
同时访问 TLB 和 Cache
假设每个 Cache line 中包含 2^b 字节的数据，一共有 2^L 个 cache set，寻址长度为 L+b （字节寻址）
页面大小为 2^k 字节
第一、二种情况：Cache 容量 <= 页面大小 L+b >= k
如图所示
VA[L+b-1:0]来寻找对应 cache line 的数据和 tag
VA 高位找 TLB 对应的 PA
将 PA 和 cache 中的 tag 对比，判断命中
避免重名效果：VA[L+b-1:0] 直接映射的内容一致，那么必在一个 set 之中
（本质上是根据 PA 来分 cache 映射）
index 部分相同的不同物理地址才可能占据不同的 way
#问题 会不会出现页重名的现象？不会
Cache 的大小被页面大小给限制了，由此如果需要增大 cache，则增大 way 的数量，但需要比较所有的 tag，那么在比较时会占用大量时序
第三种情况：Cache 容量 > 页面大小 L+b > k
重名问题：页大小：4KB，cache 大小：8KB
解决方案
- 设置多个 bank
- 利用 L2 cache 解决重名问题
- VA2 在访问 cache 时缺失
- 转换 PA 去访问 L2 cache
- L2 cache 的 a1(不需要包含 offset) 不等于 va2，表明 L1 cache 已经有 VA1 了
- 此时将 L1 cache 中的 VA1 进行 clean 并且置位无效
VIVT
如果 cache 命中，不需要访问 TLB
解决重名方式也是L2 cache ，区别是需要存储完整的 VA1
总结
| 类型 | 优点 | 缺点 | 应用场景 |
|---|---|---|---|
| PIPT | 没有重名问题 | 查找速度慢 | 用于 L2 |
| VIPT | 适中 | 适中 | 大部分处理器使用 |
| VIVT | 访问速度快，不需要 TLB 转换物理地址 | 重名问题出现频繁 |
总结
引入虚拟存储器的优点
-
可以让程序有独立的地址空间，每个程序都有 32 位 4GB 的地址空间，不需要限定范围
-
引入虚拟空间和物理空间的映射，有效利用碎片化的物理空间
-
存在多个进程时，当物理空间大小不够时，虚拟存储器可以让进程都正常运行，保存在硬盘的空间称为 swap 区，可以等效实际应用的物理内存大小为 swap + 物理内存
-
利用虚拟存储器，可以管理每个页的权限
-
Va 在访问 TLB
- 命中
- 获得 PA
- Miss
- mmu 访问时报 page fault
- 再将调入程序异常地址，保存好 VA
- 操作系统根据保存的 VA 找到硬盘里对应位置，将对应的页进行替换
- 指令重新发射，重新访问
- Mmu 没有 page fault
- Mmu 查询页表，获得 PTE 的状态
- mmu 访问时报 page fault
- 命中
访问存储器的时间以 ms 记
原文地址：https://blog.csdn.net/qq_41703711/article/details/144330363
免责声明：本站文章内容转载自网络资源，如本站内容侵犯了原著者的合法权益，可联系本站删除。更多内容请关注自学内容网（zxcms.com）！