4. TLB管理与维护：TLB结构、TLB失效操作、TLB锁定、TLB性能优化技巧
内存管理单元（MMU）里，TLB 绝对是个关键角色。说白了，它就是页表的硬件缓存。CPU 每次访问内存，都要先查 TLB。命中，万事大吉；没命中，就得去查页表，那代价可就大了。
我刚开始做嵌入式优化时，总觉得 TLB 是硬件的事，软件不用管。直到有一次，一个视频处理项目在帧率上死活上不去，抓破头皮才发现是 TLB 抖动太厉害。从那以后，我对 TLB 的敬畏心就上来了。
4.1 TLB 的内部结构
ARMv7 的 TLB 不是一个大池子，它分了好几层。咱们先看看它的基本组成。
| TLB 层级 | 典型大小 | 关联方式 | 存储内容 |
|---|---|---|---|
| 微 TLB（Micro TLB） | 8-32 项 | 全相联 | 最近使用的页表项 |
| 主 TLB（Main TLB） | 64-512 项 | 组相联 | 全部活跃页表项 |
| 统一 TLB（Unified TLB） | 视具体核而定 | 组相联 | 指令 + 数据混合 |
微 TLB 在 Cortex-A 系列里很常见。它响应极快，通常一个时钟周期就能出结果。主 TLB 稍慢，但容量大。我个人习惯把微 TLB 看作「热缓存」，主 TLB 是「温缓存」。查 TLB 时，先走微 TLB，没命中再走主 TLB，最后才去查页表。
关键点：TLB 的每一项都包含虚拟地址、物理地址、权限位、属性位（如可缓存、可共享）以及 ASID（地址空间标识符）。ASID 的作用是区分不同进程的 TLB 项，避免进程切换时把整个 TLB 刷掉。
4.2 TLB 失效操作
TLB 失效，就是 TLB 里没有你要的地址映射。这时候 MMU 会触发一个异常，去查页表。查页表的过程叫「页表遍历」（Page Table Walk）。
页表遍历的代价有多大？我举个例子：如果页表在 L2 缓存里，大概几十个周期；如果页表在 DDR 里，那就是几百个周期。你想想看，一个本应几个周期完成的内存访问，因为 TLB 失效，硬生生拖成了几百个周期，这性能损失谁能扛得住？
ARMv7 支持两种页表格式：
- 短描述符格式（Short Descriptor Format）：两级页表，支持 1MB 节、64KB 大页、4KB 小页。这是最常见的格式。
- 长描述符格式（Long Descriptor Format）：三级页表，支持 2MB 大页和 4KB 小页，用于大物理地址扩展（LPAE）。
TLB 失效后，硬件自动完成页表遍历。但有些场景下，我们需要手动操作 TLB。比如：
- 修改了页表，需要让 TLB 中的旧项失效。
- 进程切换，需要刷掉旧进程的 TLB 项。
- 内存映射发生变化（如 mmap、munmap）。
手动失效操作通过 CP15 协处理器完成。常用的指令有：
// 使整个 TLB 失效（所有条目）
MRC p15, 0, r0, c8, c7, 0 // TLBIALL
// 使指定 ASID 的 TLB 项失效
MRC p15, 0, r0, c8, c3, 0 // TLBIMVA
// 使指定 MVA（修改后的虚拟地址）的 TLB 项失效
MRC p15, 0, r0, c8, c1, 0 // TLBIMVAA注意：我曾经在项目里犯过一个低级错误——修改页表后忘了刷 TLB。结果程序跑起来时好时坏，查了两天才定位到问题。记住：修改页表后，必须执行 DSB（数据同步屏障）和 ISB（指令同步屏障），确保 TLB 失效操作生效。
4.3 TLB 锁定
TLB 锁定是个好东西。它可以把关键的页表项「钉」在 TLB 里，防止被替换出去。这对实时性要求高的场景特别有用。
ARMv7 的 TLB 锁定通过 CP15 的锁定寄存器实现。锁定操作分两步：
- 设置锁定寄存器，指定要锁定的 TLB 槽位。
- 加载页表项到 TLB，该条目自动被锁定。
举个例子，假设我们要锁定中断向量表所在的页：
// 锁定 TLB 槽位 0
MRC p15, 0, r0, c10, c0, 0 // 读取 TLB 锁定寄存器
ORR r0, r0, #0x1 // 设置锁定位
MCR p15, 0, r0, c10, c0, 0 // 写入锁定寄存器
// 访问中断向量表，触发 TLB 加载
LDR r1, [r0, #0x1000] // 假设中断向量表在 0x1000 偏移处
// 解锁
MRC p15, 0, r0, c10, c0, 0
BIC r0, r0, #0x1
MCR p15, 0, r0, c10, c0, 0我的经验：TLB 锁定不要滥用。锁得太多，剩下的 TLB 项就少了，反而可能增加 TLB 失效。我一般只锁定 2-4 个最关键的表项，比如中断向量表、调度器代码所在的页。锁定前，先用性能计数器观察一下 TLB 失效分布，锁定那些失效次数最多的页。
4.4 TLB 性能优化技巧
优化 TLB 性能，核心目标就一个：提高命中率。下面是我在实践中总结的几个技巧。
4.4.1 利用大页减少 TLB 压力
TLB 的条目数是有限的。如果你用 4KB 小页，要覆盖 1MB 内存需要 256 个 TLB 项。如果用 1MB 大页，只需要 1 个 TLB 项。差距一目了然。
ARMv7 支持多种页大小：
| 页大小 | 覆盖 1MB 所需 TLB 项数 | 适用场景 |
|---|---|---|
| 4KB | 256 | 小内存、细粒度控制 |
| 64KB | 16 | 中等内存、DMA 缓冲区 |
| 1MB | 1 | 大块连续内存、帧缓冲 |
我建议：对于大块连续内存（如视频帧缓冲、显示缓冲区），尽量用 1MB 节映射。这能显著降低 TLB 失效次数。
4.4.2 内存访问模式优化
TLB 喜欢「空间局部性」和「时间局部性」。说白了，就是访问地址要集中，访问频率要高。
- 避免跨页访问：如果一个数据结构横跨两个页，访问它就会触发两次 TLB 加载。尽量把热数据对齐到页边界。
- 顺序访问优于随机访问：顺序访问时，TLB 可以预取。随机访问则容易导致 TLB 抖动。
- 减少进程切换：每次进程切换都可能刷 TLB（如果 ASID 用完了）。频繁切换进程，TLB 命中率会直线下降。
4.4.3 使用 ASID 避免全局刷 TLB
ARMv7 的 TLB 支持 ASID。每个进程分配一个唯一的 ASID，TLB 项会带上这个标识。进程切换时，只要 ASID 不同，TLB 项就不会冲突，不需要刷 TLB。
但 ASID 是有限的（通常 8 位，最多 256 个）。当 ASID 用完后，必须回收。回收时，需要刷掉所有 TLB 项。这个操作代价很大。
优化思路：我一般会预留几个 ASID 给关键进程（如实时任务），确保它们不会被回收。普通进程则共享剩余的 ASID 池。这样既能享受 ASID 带来的好处，又能避免关键进程的 TLB 被刷掉。
4.4.4 TLB 预取
有些 ARM 核支持 TLB 预取。当检测到顺序访问模式时，硬件会自动预取后续页的 TLB 项。这个功能默认开启，一般不需要手动干预。
但要注意：如果内存访问模式是随机的，TLB 预取反而会浪费带宽。这种情况下，可以考虑关闭预取功能（如果硬件支持的话）。
4.5 TLB 性能分析工具
优化 TLB 性能，不能靠猜。ARM 提供了性能监视单元（PMU），可以统计 TLB 相关事件。
| PMU 事件 | 事件编号 | 说明 |
|---|---|---|
| L1 指令 TLB 失效 | 0x01 | 指令访问时 TLB 未命中 |
| L1 数据 TLB 失效 | 0x02 | 数据访问时 TLB 未命中 |
| TLB 锁定命中 | 0x03 | 访问锁定的 TLB 项 |
| 页表遍历次数 | 0x04 | TLB 失效后查页表的次数 |
使用 PMU 的步骤很简单：
- 使能 PMU（通过 PMCR 寄存器）。
- 选择要计数的事件（通过 PMXEVTYPER 寄存器）。
- 读取计数器（通过 PMXEVCNTR 寄存器）。
我习惯在关键代码段前后读取计数器，计算 TLB 失效次数。如果失效次数超过总访问次数的 1%，就该考虑优化了。
一个小技巧：在调试阶段，可以用 JTAG 或仿真器直接读取 TLB 内容。看看哪些页占用了 TLB 项，哪些页频繁被替换。这比单纯看计数器更直观。
4.6 实战：TLB 优化案例
最后分享一个我实际做过的优化案例。一个网络数据包处理程序，每秒要处理 10 万个包。每个包的处理涉及多次内存访问，TLB 失效成了瓶颈。
优化前：
- TLB 失效率：3.2%
- 平均包处理时间：12.5 微秒
优化措施：
- 将数据包缓冲区映射为 1MB 大页，减少 TLB 项占用。
- 将热数据（如描述符、统计信息）对齐到页边界，避免跨页访问。
- 锁定中断处理代码所在的页，防止被替换。
优化后：
- TLB 失效率：0.4%
- 平均包处理时间：8.1 微秒
性能提升了 35%。嗯，这就是 TLB 优化的价值。