Skip to content

Latest commit

 

History

History
75 lines (46 loc) · 7.05 KB

17.4-build-large-cache.md

File metadata and controls

75 lines (46 loc) · 7.05 KB

17.4 构建大的缓存表

接下来,我将通过介绍几个例子来看一下如何使用之前介绍的内容。我会从一个非常简单的例子开始,之后我们会看一下Garbage Collector,因为很多同学都问了Garbage Collector的问题,所以GC是一个可以深入探讨的好话题。

首先我想讨论的是一个非常简单的应用,它甚至都没有在论文中提到,但它却是展示这节课的内容非常酷的一个方法。这个应用里是构建一个大的缓存表,什么是缓存表?它是用来记录一些运算结果的表单。举个例子,你可以这么想,下面是我们的表单,它从0开始到n。表单记录的是一些费时的函数运算的结果,函数的参数就是0到n之间的数字。

如果这个表单在最开始的时候就预计算好了,那么当你想知道f(i)的结果是什么时,你需要做的就是查看表单的i槽位,并获取f(i)的值。这样你可以将一个费时的函数运算转变成快速的表单查找,所以这里一个酷的技巧就是预先将费时的运算结果保存下来。如果相同的计算需要运行很多很多次,那么预计算或许是一个聪明的方案。

这里的挑战是,表单可能会很大,或许会大过物理内存,这里可以使用论文提到的虚拟内存特性来解决这个挑战。

首先,你需要分配一个大的虚拟地址段,但是并不分配任何物理内存到这个虚拟地址段。这里只是从地址空间获取了很大一段地址,并说我将要使用地址空间的这部分来保存表单。

但是现在表单中并没有内容,表单只是一段内存地址。如果你现在查找表单的i槽位,会导致Page Fault。所以这里的计划是,在发生Page Fault时,先针对对应的虚拟内存地址分配物理内存Page,之后计算f(i),并将结果存储于tb[i],也就是表单的第i个槽位,最后再恢复程序的运行。

这种方式的优势是,如果你需要再次计算f(i),你不需要在进行任何费时的计算,只需要进行表单查找。即使接下来你要查找表单的i+1槽位,因为一个内存Page可能可以包含多个表单项,这时也不用通过Page Fault来分配物理内存Page。

不过如果你一直这么做的话,因为表单足够大,你最终还是会消耗掉所有的物理内存。所以Page Fault Handler需要在消耗完所有的内存时,回收一些已经使用过的物理内存Page。当然,你需要修改已经被回收了的物理内存对应的PTE的权限,这样在将来使用对应地址段时,就可以获得Page Fault。所以你需要使用Prot1或者ProtN来减少这些Page的accessbility。

学生提问:在分配物理内存Page时,我们需要让操作系统映射到地址空间的特定地址,否则的话可能会映射到任意地址,是吧?

Frans教授:操作系统会告知是哪个地址,并且这里可能是任意的地址。

为了更具体的描述这里的应用,我这里有个小的实现,我们可以看一看这里是如何使用现有的Unix特性。

在main函数中,首先调用setup_sqrt_region函数,它会从地址空间分配地址段,但是又不实际分配物理Page。之后调用test_sqrt_region。

在test_sqrt_region中,会以随机数来遍历表单,并通过实际运算对应的平方根值,来检查表单中相应位置值是不是保存了正确的平方根值。在test_sqrt_region运行的过程中,会产生Page Fault,因为现在还并没有分配任何物理内存Page。

应用程序该如何收到Page Fault呢?

在setup_sqrt_region函数中有一段代码,通过将handle_sigsegv函数注册到了SIGSEGV事件。这样当segfault或者Page Fault发生时,内核会调用handle_sigsegv函数。

handle_sigsegv函数与你们之前看过很多很多次的trap代码非常相似。

  • 它首先会获取触发Page Fault的地址,
  • 之后调用mmap对这个虚拟内存地址分配一个物理内存Page(注,这里是mmap映射匿名内存)。这里的虚拟内存地址就是我们想要在表单中用来保存数据的地址。
  • 然后我们为这个Page中所有的表单项都计算对应的平方根值,之后就完事了。

这个应用程序有点极端,它在运行的时候只会使用一个物理内存Page,所以不论上一次使用的Page是什么,在handle_sigsegv的最后都会通过munmap释放它。所以我们有一个巨大的表单,但是它只对应一个物理内存Page。

接下来我将运行一下这个应用程序。test_sqrt_region会随机查看表单的内容,所以可以假设这会触发很多Page Fault,但是可以看出表单中的所有内容都能通过检查。

所以,尽管这里有一个巨大的表单用来保存平方根,但是实际在物理内存中只有一个内存Page。这是一个简单的例子,它展示了用户应用程序使用之前提到的虚拟内存特性之后可以做的一些酷的事情。

学生提问:能再讲一下为什么一个物理内存Page就可以工作吗?我觉得这像是lazy allocation,但是区别又是什么呢?

Frans教授:当我们刚刚完成设置时,我们一个内存Page都没有,setup_sqrt_region分配了一个地址段,但是又立即通过munmap将与这个地址段关联的内存释放了。所以在启动的最开始对于表单并没有一个物理内存Page与之关联。

之后,当我们得到了一个Page Fault,这意味着整个表单对应的地址中至少有一个Page没有被映射,虽然实际上我们一个Page都没有映射。现在我们得到了一个Page Fault,我们只需要映射一个Page,在这个Page中,我们会存入i,i+1。。。的平方根(注,因为一个Page4096字节,一个double8个字节,所以一个Page可以保存512个表单项)。

因为这是第一个Page Fault,之前并没有映射了内存Page,所以不需要做任何事情。

之后,程序继续运行并且查找了表单中的更多项,如果查找一个没有位于已分配Page上的表单项时,会得到另一个Page Fault。这时,在handle_sigsegv会分配第二个内存Page,并为这个Page计算平方根的值。之后会munmap记录在last_page_base中的内存。

当然,在实际中我们永远也不会这么做,在实际中至少会保留一些内存Page,这里只是以一种极端的方式展示,你可以只通过内存中的一个Page来表示一个巨大的表单。所以在handle_sigsegv中,会释放上一次映射的内存Page。

之后程序继续运行,所以在任何一个时间,只有一个物理内存Page被使用了。很明显,你们在实际中不会这么做,这里更多的是展示前面提到特性的能力。