更新 ARM TTBR(翻译表基址寄存器)的缺点是什么? [英] What is the downside of updating ARM TTBR(Translate Table Base Register)?

问题描述

这个问题与这个问题有关:虽然fork";对于一个进程，为什么Linux内核会为每个新创建的进程复制内核页表的内容?

This question is related to this one: 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 的缺点是什么?

I found that Linux kernel tries to avoid updating TTBR when switching between user land and kernel land by copying the content of swapper page table into every newly created page table in function pgd_alloc. Question is: What is the downside of updating ARM TTBR?

推荐答案

更新 TTBR(翻译表基址寄存器)^Note1 并启用 MMU 有很多危险.需要考虑中断、页面错误、TLB(MMU 缓存)以及 L1 和 L2 缓存.在不同的系统上，缓存可能是 PIPT 或 VIVT(物理或虚拟标记)，可能有或可能不存在 L1 或 L2 缓存.

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 缓存相形见绌.更新 MMU 表和执行 TLB 刷新的影响比从 L1/L2 代码和数据缓存中删除不需要的影响要小.至少一个 TLB 值 1/4KB 或超过 1/100 个缓存行(重新填充的成本).在某些情况下，TLB 条目可能为 1MB.

People seem overly concerned about the MMU and TLB for efficiency. They are always dwarfed by the primary L1/L2 caches in performance considerations. It is a smaller impact to update the MMU tables and perform TLB flushes than it is to have un-needed evictions from the L1/L2 code and data caches. At a minimum a TLB is worth 1/4KB or over 1/100 cache lines (cost to repopulate). In some cases, the TLB entry maybe 1MB.

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

Some data/code in the L1/L2 user space may need to be evicted on context switches. However, for very frequent small work-loads, a user context switch may keep code and data in the L1/L2. For example a media player doing large CPU intensive decoding and some cron task checking to see no new email is on a server. The switch to and back from the 'cron' task may result in code remaining in the L2 cache for the video decoding to use.

更新 ARM TTBR 的缺点是什么?

What is the downside of updating ARM TTBR?

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

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.

Note1: The TTBR is a pointer to a physical 16k aligned memory region that is the first level of the ARM MMU. Each entry is 1MB (on 32bit systems) and may point to another table; often called L2.

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

Note2: You might do this in a boot loader or places where you are migrating system level code between memory devices. Ie, update the TTBR with identical tables is of no consequence by itself. It is when the tables differ that weird things will happen.

这篇关于更新 ARM TTBR(翻译表基址寄存器)的缺点是什么?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！