linux - 更新 ARM TTBR(转换表基址寄存器)的缺点是什么？

Question

这个问题与这个问题有关: While "fork"ing a process, why does Linux kernel copy the content of kernel page table for every newly created process?

我发现 Linux 内核试图通过在函数 pgd_alloc 中将交换页表的内容复制到每个新创建的页表中来避免在用户空间和内核空间之间切换时更新 TTBR。问题是:更新 ARM TTBR 的缺点是什么？

Answer 1

使用 MMU 启用更新 TTBR(转换表基址寄存器)^Note1 有很多风险。需要考虑中断、页面错误、TLB(MMU 缓存)以及 L1 和 L2 缓存。在不同的系统上，the caches maybe PIPT or VIVT (物理或虚拟标记)，可能存在也可能不存在 L1 或 L2 缓存。

人们似乎过分关注 MMU 和 TLB 的效率。在性能方面，它们总是与主要的 L1/L2 缓存相形见绌。更新 MMU 表和执行 TLB 刷新的影响比从 L1/L2 代码和数据缓存中进行不必要的驱逐要小。至少一个 TLB 相当于 1/4KB 或超过 1/100 缓存行(重新填充的成本)。在某些情况下，TLB 条目可能为 1MB。

L1/L2 用户空间中的一些数据/代码可能需要在上下文切换时被逐出。然而，对于非常频繁的小工作负载，用户上下文切换可能会将代码和数据保留在 L1/L2 中。例如，媒体播放器执行大型 CPU 密集型解码和一些 cron 任务检查以查看服务器上没有新电子邮件。切换到“cron”任务和从“cron”任务返回可能会导致代码保留在 L2 缓存中以供视频解码使用。

What is the downside of updating ARM TTBR?

除非从/到表相同，否则您必须在更新期间保持内存的系统 View 一致。^{注意 2} 这自然会导致 IRQ 延迟和实现的复杂性，因为您需要同步许多子系统。此外，Linux MM(内存管理)代码与体系结构无关。它处理各种各样的 MMU 子系统。目标永远不是局部优化(在架构级别)，而是在通用层进行全局优化。

注意 1:TTBR 是指向物理 16k 对齐内存区域的指针，它是 ARM MMU 的第一级。每个条目为 1MB(在 32 位系统上)并且可能指向另一个表；通常称为 L2。

注意 2:您可以在引导加载程序中或在内存设备之间迁移系统级代码的地方执行此操作。即，用相同的表更新 TTBR 本身并不重要。当表格不同时，就会发生奇怪的事情。