1 .. include:: ../disclaimer-zh_CN.rst 2 3 :Original: Documentation/core-api/cachetlb.rst 4 5 :翻译: 6 7 司延腾 Yanteng Si <siyanteng@loongson.cn> 8 周彬彬 Binbin Zhou <zhoubinbin@loongson.cn> 9 10 :校译: 11 12 吴想成 Wu XiangCheng <bobwxc@email.cn> 13 14 .. _cn_core-api_cachetlb: 15 16 ====================== 17 Linux下的缓存和TLB刷新 18 ====================== 19 20 :作者: David S. Miller <davem@redhat.com> 21 22 *译注：TLB，Translation Lookaside Buffer，页表缓存/变换旁查缓冲器* 23 24 本文描述了由Linux虚拟内存子系统调用的缓存/TLB刷新接口。它列举了每个接 25 口，描述了它的预期目的，以及接口被调用后的预期副作用。 26 27 下面描述的副作用是针对单处理器的实现，以及在单个处理器上发生的情况。若 28 为SMP，则只需将定义简单地扩展一下，使发生在某个特定接口的副作用扩展到系 29 统的所有处理器上。不要被这句话吓到，以为SMP的缓存/tlb刷新一定是很低 30 效的，事实上，这是一个可以进行很多优化的领域。例如，如果可以证明一个用 31 户地址空间从未在某个cpu上执行过（见mm_cpumask()），那么就不需要在该 32 cpu上对这个地址空间进行刷新。 33 34 首先是TLB刷新接口，因为它们是最简单的。在Linux下，TLB被抽象为cpu 35 用来缓存从软件页表获得的虚拟->物理地址转换的东西。这意味着，如果软件页 36 表发生变化，这个“TLB”缓存中就有可能出现过时（脏）的翻译。因此，当软件页表 37 发生变化时，内核会在页表发生 *变化后* 调用以下一种刷新方法： 38 39 1) ``void flush_tlb_all(void)`` 40 41 最严格的刷新。在这个接口运行后，任何以前的页表修改都会对cpu可见。 42 43 这通常是在内核页表被改变时调用的，因为这种转换在本质上是“全局”的。 44 45 2) ``void flush_tlb_mm(struct mm_struct *mm)`` 46 47 这个接口从TLB中刷新整个用户地址空间。在运行后，这个接口必须确保 48 以前对地址空间‘mm’的任何页表修改对cpu来说是可见的。也就是说，在 49 运行后，TLB中不会有‘mm’的页表项。 50 51 这个接口被用来处理整个地址空间的页表操作，比如在fork和exec过程 52 中发生的事情。 53 54 3) ``void flush_tlb_range(struct vm_area_struct *vma, 55 unsigned long start, unsigned long end)`` 56 57 这里我们要从TLB中刷新一个特定范围的（用户）虚拟地址转换。在运行后， 58 这个接口必须确保以前对‘start’到‘end-1’范围内的地址空间‘vma->vm_mm’ 59 的任何页表修改对cpu来说是可见的。也就是说，在运行后，TLB中不会有 60 ‘mm’的页表项用于‘start’到‘end-1’范围内的虚拟地址。 61 62 “vma”是用于该区域的备份存储。主要是用于munmap()类型的操作。 63 64 提供这个接口是希望端口能够找到一个合适的有效方法来从TLB中删除多 65 个页面大小的转换，而不是让内核为每个可能被修改的页表项调用 66 flush_tlb_page(见下文)。 67 68 4) ``void flush_tlb_page(struct vm_area_struct *vma, unsigned long addr)`` 69 70 这一次我们需要从TLB中删除PAGE_SIZE大小的转换。‘vma’是Linux用来跟 71 踪进程的mmap区域的支持结构体，地址空间可以通过vma->vm_mm获得。另 72 外，可以通过测试（vma->vm_flags & VM_EXEC）来查看这个区域是否是 73 可执行的（因此在split-tlb类型的设置中可能在“指令TLB”中）。 74 75 在运行后，这个接口必须确保之前对用户虚拟地址“addr”的地址空间 76 “vma->vm_mm”的页表修改对cpu来说是可见的。也就是说，在运行后，TLB 77 中不会有虚拟地址‘addr’的‘vma->vm_mm’的页表项。 78 79 这主要是在故障处理时使用。 80 81 5) ``void update_mmu_cache(struct vm_area_struct *vma, 82 unsigned long address, pte_t *ptep)`` 83 84 在每个缺页异常结束时，这个程序被调用，以告诉体系结构特定的代码，在 85 软件页表中，在地址空间“vma->vm_mm”的虚拟地址“地址”处，现在存在 86 一个翻译。 87 88 可以用它所选择的任何方式使用这个信息来进行移植。例如，它可以使用这 89 个事件来为软件管理的TLB配置预装TLB转换。目前sparc64移植就是这么干 90 的。 91 92 接下来，我们有缓存刷新接口。一般来说，当Linux将现有的虚拟->物理映射 93 改变为新的值时，其顺序将是以下形式之一:: 94 95 1) flush_cache_mm(mm); 96 change_all_page_tables_of(mm); 97 flush_tlb_mm(mm); 98 99 2) flush_cache_range(vma, start, end); 100 change_range_of_page_tables(mm, start, end); 101 flush_tlb_range(vma, start, end); 102 103 3) flush_cache_page(vma, addr, pfn); 104 set_pte(pte_pointer, new_pte_val); 105 flush_tlb_page(vma, addr); 106 107 缓存级别的刷新将永远是第一位的，因为这允许我们正确处理那些缓存严格， 108 且在虚拟地址被从缓存中刷新时要求一个虚拟地址的虚拟->物理转换存在的系统。 109 HyperSparc cpu就是这样一个具有这种属性的cpu。 110 111 下面的缓存刷新程序只需要在特定的cpu需要的范围内处理缓存刷新。大多数 112 情况下，这些程序必须为cpu实现，这些cpu有虚拟索引的缓存，当虚拟->物 113 理转换被改变或移除时，必须被刷新。因此，例如，IA32处理器的物理索引 114 的物理标记的缓存没有必要实现这些接口，因为这些缓存是完全同步的，并 115 且不依赖于翻译信息。 116 117 下面逐个列出这些程序: 118 119 1) ``void flush_cache_mm(struct mm_struct *mm)`` 120 121 这个接口将整个用户地址空间从高速缓存中刷掉。也就是说，在运行后， 122 将没有与‘mm’相关的缓存行。 123 124 这个接口被用来处理整个地址空间的页表操作，比如在退出和执行过程 125 中发生的事情。 126 127 2) ``void flush_cache_dup_mm(struct mm_struct *mm)`` 128 129 这个接口将整个用户地址空间从高速缓存中刷新掉。也就是说，在运行 130 后，将没有与‘mm’相关的缓存行。 131 132 这个接口被用来处理整个地址空间的页表操作，比如在fork过程中发生 133 的事情。 134 135 这个选项与flush_cache_mm分开，以允许对VIPT缓存进行一些优化。 136 137 3) ``void flush_cache_range(struct vm_area_struct *vma, 138 unsigned long start, unsigned long end)`` 139 140 在这里，我们要从缓存中刷新一个特定范围的（用户）虚拟地址。运行 141 后，在“start”到“end-1”范围内的虚拟地址的“vma->vm_mm”的缓存中 142 将没有页表项。 143 144 “vma”是被用于该区域的备份存储。主要是用于munmap()类型的操作。 145 146 提供这个接口是希望端口能够找到一个合适的有效方法来从缓存中删 147 除多个页面大小的区域， 而不是让内核为每个可能被修改的页表项调 148 用 flush_cache_page (见下文)。 149 150 4) ``void flush_cache_page(struct vm_area_struct *vma, unsigned long addr, unsigned long pfn)`` 151 152 这一次我们需要从缓存中删除一个PAGE_SIZE大小的区域。“vma”是 153 Linux用来跟踪进程的mmap区域的支持结构体，地址空间可以通过 154 vma->vm_mm获得。另外，我们可以通过测试（vma->vm_flags & 155 VM_EXEC）来查看这个区域是否是可执行的（因此在“Harvard”类 156 型的缓存布局中可能是在“指令缓存”中）。 157 158 “pfn”表示“addr”所对应的物理页框（通过PAGE_SHIFT左移这个 159 值来获得物理地址）。正是这个映射应该从缓存中删除。 160 161 在运行之后，对于虚拟地址‘addr’的‘vma->vm_mm’，在缓存中不会 162 有任何页表项，它被翻译成‘pfn’。 163 164 这主要是在故障处理过程中使用。 165 166 5) ``void flush_cache_kmaps(void)`` 167 168 只有在平台使用高位内存的情况下才需要实现这个程序。它将在所有的 169 kmaps失效之前被调用。 170 171 运行后，内核虚拟地址范围PKMAP_ADDR(0)到PKMAP_ADDR(LAST_PKMAP) 172 的缓存中将没有页表项。 173 174 这个程序应该在asm/highmem.h中实现。 175 176 6) ``void flush_cache_vmap(unsigned long start, unsigned long end)`` 177 ``void flush_cache_vunmap(unsigned long start, unsigned long end)`` 178 179 在这里，在这两个接口中，我们从缓存中刷新一个特定范围的（内核） 180 虚拟地址。运行后，在“start”到“end-1”范围内的虚拟地址的内核地 181 址空间的缓存中不会有页表项。 182 183 这两个程序中的第一个是在vmap_range()安装了页表项之后调用的。 184 第二个是在vunmap_range()删除页表项之前调用的。 185 186 还有一类cpu缓存问题，目前需要一套完全不同的接口来正确处理。最大 187 的问题是处理器的数据缓存中的虚拟别名。 188 189 .. note:: 190 191 这段内容有些晦涩，为了减轻中文阅读压力，特作此译注。 192 193 别名（alias）属于缓存一致性问题，当不同的虚拟地址映射相同的 194 物理地址，而这些虚拟地址的index不同，此时就发生了别名现象(多 195 个虚拟地址被称为别名)。通俗点来说就是指同一个物理地址的数据被 196 加载到不同的cacheline中就会出现别名现象。 197 198 常见的解决方法有两种：第一种是硬件维护一致性，设计特定的cpu电 199 路来解决问题（例如设计为PIPT的cache）；第二种是软件维护一致性， 200 就是下面介绍的sparc的解决方案——页面染色，涉及的技术细节太多， 201 译者不便展开，请读者自行查阅相关资料。 202 203 您的移植是否容易在其D-cache中出现虚拟别名？嗯，如果您的D-cache 204 是虚拟索引的，且cache大于PAGE_SIZE（页大小），并且不能防止同一 205 物理地址的多个cache行同时存在，您就会遇到这个问题。 206 207 如果你的D-cache有这个问题，首先正确定义asm/shmparam.h SHMLBA， 208 它基本上应该是你的虚拟寻址D-cache的大小（或者如果大小是可变的， 209 则是最大的可能大小）。这个设置将迫使SYSv IPC层只允许用户进程在 210 这个值的倍数的地址上对共享内存进行映射。 211 212 .. note:: 213 214 这并不能解决共享mmaps的问题，请查看sparc64移植解决 215 这个问题的一个方法（特别是 SPARC_FLAG_MMAPSHARED）。 216 217 接下来，你必须解决所有其他情况下的D-cache别名问题。请记住这个事 218 实，对于一个给定的页面映射到某个用户地址空间，总是至少还有一个映 219 射，那就是内核在其线性映射中从PAGE_OFFSET开始。因此，一旦第一个 220 用户将一个给定的物理页映射到它的地址空间，就意味着D-cache的别名 221 问题有可能存在，因为内核已经将这个页映射到它的虚拟地址。 222 223 ``void copy_user_page(void *to, void *from, unsigned long addr, struct page *page)`` 224 ``void clear_user_page(void *to, unsigned long addr, struct page *page)`` 225 226 这两个程序在用户匿名或COW页中存储数据。它允许一个端口有效地 227 避免用户空间和内核之间的D-cache别名问题。 228 229 例如，一个端口可以在复制过程中把“from”和“to”暂时映射到内核 230 的虚拟地址上。这两个页面的虚拟地址的选择方式是，内核的加载/存 231 储指令发生在虚拟地址上，而这些虚拟地址与用户的页面映射是相同 232 的“颜色”。例如，Sparc64就使用这种技术。 233 234 “addr”参数告诉了用户最终要映射这个页面的虚拟地址，“page”参 235 数给出了一个指向目标页结构体的指针。 236 237 如果D-cache别名不是问题，这两个程序可以简单地直接调用 238 memcpy/memset而不做其他事情。 239 240 ``void flush_dcache_page(struct page *page)`` 241 242 任何时候，当内核写到一个页面缓存页，或者内核要从一个页面缓存 243 页中读出，并且这个页面的用户空间共享/可写映射可能存在时， 244 这个程序就会被调用。 245 246 .. note:: 247 248 这个程序只需要为有可能被映射到用户进程的地址空间的 249 页面缓存调用。因此，例如，处理页面缓存中vfs符号链 250 接的VFS层代码根本不需要调用这个接口。 251 252 “内核写入页面缓存的页面”这句话的意思是，具体来说，内核执行存 253 储指令，在该页面的页面->虚拟映射处弄脏该页面的数据。在这里，通 254 过刷新的手段处理D-cache的别名是很重要的，以确保这些内核存储对 255 该页的用户空间映射是可见的。 256 257 推论的情况也同样重要，如果有用户对这个文件有共享+可写的映射， 258 我们必须确保内核对这些页面的读取会看到用户所做的最新的存储。 259 260 如果D-cache别名不是一个问题，这个程序可以简单地定义为该架构上 261 的nop。 262 263 在folio->flags (PG_arch_1)中有一个位是“架构私有”。内核保证， 264 对于分页缓存的页面，当这样的页面第一次进入分页缓存时，它将清除 265 这个位。 266 267 这使得这些接口可以更有效地被实现。如果目前没有用户进程映射这个 268 页面，它允许我们“推迟”（也许是无限期）实际的刷新过程。请看 269 sparc64的flush_dcache_page和update_mmu_cache实现，以了解如 270 何做到这一点。 271 272 这个想法是，首先在flush_dcache_page()时，如果page->mapping->i_mmap 273 是一个空树，只需标记架构私有页标志位。之后，在update_mmu_cache() 274 中，会对这个标志位进行检查，如果设置了，就进行刷新，并清除标志位。 275 276 .. important:: 277 278 通常很重要的是，如果你推迟刷新，实际的刷新发生在同一个 279 CPU上，因为它将cpu存储到页面上，使其变脏。同样，请看 280 sparc64关于如何处理这个问题的例子。 281 282 ``void flush_dcache_folio(struct folio *folio)`` 283 284 该函数的调用情形与flush_dcache_page()相同。它允许架构针对刷新整个 285 folio页面进行优化，而不是一次刷新一页。 286 287 ``void copy_to_user_page(struct vm_area_struct *vma, struct page *page, 288 unsigned long user_vaddr, void *dst, void *src, int len)`` 289 ``void copy_from_user_page(struct vm_area_struct *vma, struct page *page, 290 unsigned long user_vaddr, void *dst, void *src, int len)`` 291 292 当内核需要复制任意的数据进出任意的用户页时（比如ptrace()），它将使 293 用这两个程序。 294 295 任何必要的缓存刷新或其他需要发生的一致性操作都应该在这里发生。如果 296 处理器的指令缓存没有对cpu存储进行窥探，那么你很可能需要为 297 copy_to_user_page()刷新指令缓存。 298 299 ``void flush_anon_page(struct vm_area_struct *vma, struct page *page, 300 unsigned long vmaddr)`` 301 302 当内核需要访问一个匿名页的内容时，它会调用这个函数（目前只有 303 get_user_pages()）。注意：flush_dcache_page()故意对匿名页不起作 304 用。默认的实现是nop（对于所有相干的架构应该保持这样）。对于不一致性 305 的架构，它应该刷新vmaddr处的页面缓存。 306 307 ``void flush_icache_range(unsigned long start, unsigned long end)`` 308 309 当内核存储到它将执行的地址中时（例如在加载模块时），这个函数被调用。 310 311 如果icache不对存储进行窥探，那么这个程序将需要对其进行刷新。 312 313 ``void flush_icache_page(struct vm_area_struct *vma, struct page *page)`` 314 315 flush_icache_page的所有功能都可以在flush_dcache_page和update_mmu_cache 316 中实现。在未来，我们希望能够完全删除这个接口。 317 318 最后一类API是用于I/O到内核内特意设置的别名地址范围。这种别名是通过使用 319 vmap/vmalloc API设置的。由于内核I/O是通过物理页进行的，I/O子系统假定用户 320 映射和内核偏移映射是唯一的别名。这对vmap别名来说是不正确的，所以内核中任何 321 试图对vmap区域进行I/O的东西都必须手动管理一致性。它必须在做I/O之前刷新vmap 322 范围，并在I/O返回后使其失效。 323 324 ``void flush_kernel_vmap_range(void *vaddr, int size)`` 325 326 刷新vmap区域中指定的虚拟地址范围的内核缓存。这是为了确保内核在vmap范围 327 内修改的任何数据对物理页是可见的。这个设计是为了使这个区域可以安全地执 328 行I/O。注意，这个API并 *没有* 刷新该区域的偏移映射别名。 329 330 ``void invalidate_kernel_vmap_range(void *vaddr, int size) invalidates`` 331 332 在vmap区域的一个给定的虚拟地址范围的缓存，这可以防止处理器在物理页的I/O 333 发生时通过投机性地读取数据而使缓存变脏。这只对读入vmap区域的数据是必要的。
Linux® is a registered trademark of Linus Torvalds in the United States and other countries.
TOMOYO® is a registered trademark of NTT DATA CORPORATION.