Documentation/translations/zh_CN/core-api/cachetlb.rst

   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         在page->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区域的数据是必要的。