做拍福利爱福利视频网站,中国设计之家官网,推广之家,小程序开发各平台对比目录 Task 1: Eliminate allocation from sbrk()Task 2: Lazy allocationTask 3: Lazytests and Usertests 在学习了 page fault 这一节课后#xff0c;了解了操作系统是如何结合 page table 和 trap 利用 page fault 来实现一系列的神奇的功能。这个 lab 就是在 XV6 中实现 l… 目录 Task 1: Eliminate allocation from sbrk()Task 2: Lazy allocationTask 3: Lazytests and Usertests 在学习了 page fault 这一节课后了解了操作系统是如何结合 page table 和 trap 利用 page fault 来实现一系列的神奇的功能。这个 lab 就是在 XV6 中实现 lazy allocation 机制。 xv6 默认是 eager allocation也就是用户程序一旦调用 sbrk内核会立刻分配应用程序所需要的物理内存。这个实验就是将其修改为 lazy allocation用户在调用 sbrk 时不会立刻分配物理内存只是做一个记录等到程序真正读写这个内存 page 时才会因触发 page fault 而让内核分配一个实际的物理内存并修改到 page table 中。 Task 1: Eliminate allocation from sbrk() 这个 task 让我们删除 sbrk 的系统调用实现函数 sys_sbrk() 中分配物理内存的代码内核只需要增大 myproc()-sz 这个值即可。 myproc()-sz 这个值记录的当前用户进程已申请的 heap 的最大地址 代码kernel/sysproc.c uint64 sys_sbrk(void) {int addr;int n;if(argint(0, n) 0)return -1;addr myproc()-sz;// if(growproc(n) 0)// return -1;myproc()-sz n;return addr; }make qemu 后执行 echo hi 这里会发生 page fault在下面的 task 中我们将处理发生的 page fault并为其分配物理内存 page 且修改对应的 page table。 Task 2: Lazy allocation 这个 task 需要修改代码来处理 page fault 并为用户程序分配物理内存。 当 page fault 发生时程序会通过 trap 机制进入 usertrap() 函数我们可以在这里实现相关的而逻辑。SCAUSE 寄存器记录了本次 trap 发生的原因当寄存器的值为 13 或 15 时表示因 load 或 store 指令访问一个地址但没找到相应 PTE 而发生 page fault所以我们需要在 usertrap() 函数中判断 SCAUSE 寄存器的值并实现相应的 page fault 处理逻辑。 首先在 usertrap() 函数kernel/trap.c中添加对 page fault 的识别并调用 page fault handler 来处理 添加并实现 page_fault_handler() 函数代码紧跟在 usertrap 函数后面就可以 // // handle page fault // void page_fault_handler(struct proc * const p) {uint64 va r_stval(); // 触发 page fault 的虚拟地址if (p-sz va || va p-trapframe-sp) { // 如果 va 高于 sbrk 申请的地址或者低于栈顶地址p-killed 1;} else {uint64 ka (uint64) kalloc();if (ka 0) { // 如果物理内存不足p-killed 1;} else {memset((void*) ka, 0, PGSIZE); // 为这块地址填充 0va PGROUNDDOWN(va); // round the faulting virtual address down to a page boundary.// 将 va - ka 的 mapping 添加到 user page table 中if (mappages(p-pagetable, va, PGSIZE, ka, PTE_W | PTE_X | PTE_U | PTE_R) ! 0) {kfree((void*) ka);p-killed 1;}}} }还存在一个问题因为用户申请的内存并没有一定分配实际的物理内存所以在对申请但未分配的内存做 unmap 时会产生错误因此需要对 unmap 的代码进行修改当想要释放一个未分配的 page 时代码中只需要直接忽视就可以了vm.c 完成以上修改后make qemu 之后就可以正常运行 echo hi 了 Task 3: Lazytests and Usertests 前一个 task 实现了一个简单的 lazy allocation执行 echo hi 是没问题了但在更复杂的场景下仍然有许多需要考虑的事情本 task 要求完善 lazy allocation 并能够通过 lazytests 和 usertests 两个测试。 首先为了实现的方便这里将实际分配物理内存的代码逻辑封装到 alloc_memory_page() 函数kernel/vm.c中 // 分配一个实际物理内存并映射到 va 中将这个 mapping 添加到 page table 中 uint64 alloc_memory_page(uint64 va, pagetable_t pagetable) {uint64 ka (uint64) kalloc();if (ka 0) { // 如果物理内存不足return 0;}memset((void*) ka, 0, PGSIZE); // 为这块地址填充 0va PGROUNDDOWN(va); // round the faulting virtual address down to a page boundary.if (mappages(pagetable, va, PGSIZE, ka, PTE_W | PTE_X | PTE_R | PTE_U) ! 0) {kfree((void*) ka);return 0;}return ka; }这个函数通过 kalloc() 来分配一个物理内存 page并将其映射到 va 中然后将这个 mapping 添加到 page table 中。当成功时函数返回分配的物理内存地址当失败时内存不足或添加 mapping 失败函数返回 0。 我们将这个 alloc_memory_page() 函数的声明放到 defs.h 头文件中。 有了这个 alloc_memory_page 函数我们在上一个实验写的 page fault handler 就可以简化一下了分配物理内存的逻辑改为调用 alloc_memory_page 即可 // // handle page fault // void page_fault_handler(struct proc * const p) {uint64 va r_stval();if (p-sz va || va p-trapframe-sp) { // 如果 va 高于 sbrk 申请的地址或者低于栈顶地址p-killed 1;} else {if (alloc_memory_page(va, p-pagetable) 0) { // 当分配内存或添加 mapping 失败就直接杀死该进程p-killed 1;}} }修改 uvmummap() 函数当无法从 page table 中找到 va 的 PTE 时或者 PTE 未映射时直接跳过 我们还需要正确处理 fork 时父进程向子进程 copy 内存的逻辑这里需要修改 uvmcopy() 函数也是在页表不存在或 PTE 未映射时直接跳过 还有一种情况是当用户程序把通过 sbrk() 申请的内存但还未实际分配的内存地址传递给系统调用时kernel 可能会在 copyin 和 copyout 这两个函数中访问这个内存地址而 kernel 内是无法像用户程序那样走 page fault handler 来 lazy allocation 的所以我们必须在 copyin 和 copyout 函数内也实现“访问用户程序传来的内存地址时做 lazy allocation”的逻辑 这里 copyout 通过 walkaddr 来将 va 借助 user page table 来翻译得到 pa但由于我们采用了 lazy allocation 机制所以这里可能无法找到 PTE 映射所以当没有找到 PTE 映射时我们需要立刻为其分配物理内存并修改 user page table这也是上图红方框内代码的逻辑。对于 copyin 函数所做的修改类似 至此我们完成了 lazy allocation测试如下 运行 lazytests 运行 usertests