在玩具操作系统中实施巨页

时间:2017-11-16 07:26:58

标签: c operating-system kernel

我正在从麻省理工学院课程6.828开始研究JOS,这是一个类似于xv6的简化操作系统。我尝试为内存管理部分实现一个巨大的页面机制,它操作大小为4MB而不是4KB默认的内存页面。从lab2

的说明可以看出这是一个挑战性问题
  

挑战!我们使用了许多物理页面来保存KERNBASE映射的页表。使用页面目录条目中的PTE_PS(“页面大小”)位执行更节省空间的作业。原始80386不支持此位,但最近的x86处理器支持此位。因此,您必须参考当前英特尔手册的第3卷。确保您设计内核以仅在支持它的处理器上使用此优化!

某些内存区域远小于4MB,通常是4KB的几倍,例如用户模式异常堆栈,因此我们必须使用普通页面和大页面的混合。

与可能完成的工作量相比,指令中没有太多信息。我想知道在精心设计的内核中这个功能的常见做法是什么。

首先让我说明我发现并混淆的内容。

  • 目前,在mem_init()时,JOS内核以4K粒度(页面)分割所有应该是空闲的物理内存(不包括内核,IO漏洞等),并为其分配的每个页面一个PageInfo结构,以便我们最终得到一个连续的PageInfo数组。

    我已经决定内核应该以4M粒度(大页面)拆分一定数量的内存,并分配一个连续的HugePageInfo数组。这是其他内核的正确方法吗?如何确定大页面的内存百分比?

  • 该指令似乎引导我将所有内存映射为高地址之上的大页面,因为除此之外我无法弄清楚如何仅使用一两个大页面可以为我节省大量页面表。但是,由于JOS将所有内存映射到高地址之上(然后在需要时再将地址映射到低地址),这意味着我的所有内存应该作为大页面存在。

    某些物理内存是否可以成为某个大页面的一部分,同时,是某些普通页面的一部分?这对我来说没有意义。

  • 正如我可以预见的那样,在内核中引入大页面会破坏我目前拥有的许多代码和函数,包括用于页面目录遍历等等。(JOS使用2层内存寻址:page 目录和页面表,所以对于一个巨大的页面,根本没有页面表级别。)当其他内核引入大页面时,这通常是正确的吗?

0 个答案:

没有答案