Updating the TTBR (translation table base register)Note1 with the MMU enables has many perils. There are interrupts, page faults, TLB (MMU-cache) and both L1 and L2 caches to be considered. On different systems, the caches maybe PIPT or VIVT (physically or virtually tagged), there may or may not exist L1 nor L2 caches.
人们似乎过度关注 MMU 和 TLB 的效率。在性能考虑方面，它们始终与主 L1/L2 缓存相形见绌。与从 L1/L2 代码和数据缓存中进行不必要的逐出相比，更新 MMU 表和执行 TLB 刷新的影响更小。一个 TLB 至少值 1/4KB 或超过 1/100 的缓存线（重新填充的成本）。在某些情况下，TLB 条目可能有 1MB。
L1/L2 用户空间中的一些数据/代码可能需要在上下文切换时被逐出。然而，对于非常频繁的小工作负载，用户上下文切换可能会将代码和数据保留在 L1/L2 中。例如，媒体播放器执行大量 CPU 密集型解码，并进行一些 cron 任务检查以查看服务器上是否有新电子邮件。切换到“cron”任务或从“cron”任务返回可能会导致代码保留在 L2 缓存中以供视频解码使用。
更新 ARM TTBR 的缺点是什么？
Unless the from/to tables are identical you have to keep the system view of memory consistent for the duration of the update.Note2 This will naturally cause IRQ latency and complexity of implementation as you need to sync up many sub-systems. Also, the Linux MM (memory management) code is architecture agnostic. It handles a great variety of MMU sub-systems. The goal is never to optimize locally (at the architecture level) but optimize globally at the generic layers.
注1：TTBR是指向物理 16k 对齐内存区域的指针，该内存区域是 ARM MMU 的第一级。每个条目为 1MB（在 32 位系统上）并且可能指向另一个表；通常称为 L2。
注意 2：您可以在引导加载程序或在内存设备之间迁移系统级代码的位置执行此操作。即，使用相同的表更新 TTBR 本身没有任何后果。当表格不同时就会发生奇怪的事情。
