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