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======================
17Linux下的缓存和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()),那么就不需要在该
32cpu上对这个地址空间进行刷新。
33
34首先是TLB刷新接口,因为它们是最简单的。在Linux下,TLB被抽象为cpu
35用来缓存从软件页表获得的虚拟->物理地址转换的东西。这意味着,如果软件页
36表发生变化,这个“TLB”缓存中就有可能出现过时(脏)的翻译。因此,当软件页表
37发生变化时,内核会在页表发生 *变化后* 调用以下一种刷新方法:
38
391) ``void flush_tlb_all(void)``
40
41	最严格的刷新。在这个接口运行后,任何以前的页表修改都会对cpu可见。
42
43	这通常是在内核页表被改变时调用的,因为这种转换在本质上是“全局”的。
44
452) ``void flush_tlb_mm(struct mm_struct *mm)``
46
47	这个接口从TLB中刷新整个用户地址空间。在运行后,这个接口必须确保
48	以前对地址空间‘mm’的任何页表修改对cpu来说是可见的。也就是说,在
49	运行后,TLB中不会有‘mm’的页表项。
50
51	这个接口被用来处理整个地址空间的页表操作,比如在fork和exec过程
52	中发生的事情。
53
543) ``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
684) ``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
815) ``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且在虚拟地址被从缓存中刷新时要求一个虚拟地址的虚拟->物理转换存在的系统。
109HyperSparc cpu就是这样一个具有这种属性的cpu。
110
111下面的缓存刷新程序只需要在特定的cpu需要的范围内处理缓存刷新。大多数
112情况下,这些程序必须为cpu实现,这些cpu有虚拟索引的缓存,当虚拟->物
113理转换被改变或移除时,必须被刷新。因此,例如,IA32处理器的物理索引
114的物理标记的缓存没有必要实现这些接口,因为这些缓存是完全同步的,并
115且不依赖于翻译信息。
116
117下面逐个列出这些程序:
118
1191) ``void flush_cache_mm(struct mm_struct *mm)``
120
121	这个接口将整个用户地址空间从高速缓存中刷掉。也就是说,在运行后,
122	将没有与‘mm’相关的缓存行。
123
124	这个接口被用来处理整个地址空间的页表操作,比如在退出和执行过程
125	中发生的事情。
126
1272) ``void flush_cache_dup_mm(struct mm_struct *mm)``
128
129	这个接口将整个用户地址空间从高速缓存中刷新掉。也就是说,在运行
130	后,将没有与‘mm’相关的缓存行。
131
132	这个接口被用来处理整个地址空间的页表操作,比如在fork过程中发生
133	的事情。
134
135	这个选项与flush_cache_mm分开,以允许对VIPT缓存进行一些优化。
136
1373) ``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
1504) ``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
1665) ``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
1766) ``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到内核内特意设置的别名地址范围。这种别名是通过使用
319vmap/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区域的数据是必要的。
334