分页存储器管理

《分页存储器管理》由会员分享，可在线阅读，更多相关《分页存储器管理（7页珍藏版）》请在装配图网上搜索。

1、.实验 7 分页存储器管理实验性质：验证设计建议学时： 2学时一、实验目的学习 i386 处理器的二级页表硬件机制，理解分页存储器管理原理。查看 EOS应用程序进程和系统进程的二级页表映射信息，理解页目录和页表的管理方式。编程修改页目录和页表的映射关系，理解分页地址变换原理。二、预备知识阅读本书第 6章。了解 i386 处理器的二级页表硬件机制，EOS操作系统的分页存储器管理方式，以及进程地址空间的内存分布。三、实验内容3.1准备实验按照下面的步骤准备本次实验：1.启动 OS Lab。2.新建一个 EOS应用程序项目。3.2查看 EOS应用程序进程的页目录和页表使用 OS Lab打开本实验文件

2、夹中的memory.c和getcr3.asm 文件（将文件拖动到OS Lab窗口中释放即可打开）。仔细阅读这两个文件中的源代码和注释，main函数的流程图可以参见图16-1 。按照下面的步骤查看EOS应用程序进程的页目录和页表：1. 使用 memory.c 文件中的源代码替换之前创建的EOS应用程序项目中 EOSApp.c文件中的源代码。2.右键点击 “项目管理器” 窗口中的 “源文件” 文件夹节点， 在弹出的快捷菜单中选择“添加” 中的“添加新文件”。3.在弹出的“添加新文件”对话框中选择“asm 源文件”模板。4. 在“名称”中输入文件名称“ func ”。5.点击“添加”按钮添加并自动打

3、开文件func.asm 。6. 将 getcr3.asm 文件中的源代码复制到 func.asm 文件中。7. 按 F7生成修改后的 EOS应用程序项目。8. 按 F5启动调试。9.应用程序执行的过程中，会将该进程的二级页表映射信息输出到虚拟机窗口和OS Lab“输出”窗口中，输出内容如图16-2 （ a）。10. 将“输出”窗口中的内容复制到一个文本文件中。1 / 6.图16-2 ：（ a）EOS应用程序进程的二级页表映射信息（b）有应用程序进程时，系统进程的二级页表映射信息图 16-2 （ a）中第一行是CR3寄存器的值，也就是页目录所在的页框号。第一列是页目录中有效的PDE，第二列是 P

4、DE映射的页表中有效的PTE（详细的格式可以参考源代码中的注释）。注意，在标号为 0x200的 PDE对应的页表中，所有的1024个 PTE都是有效的，所以在图中省略了一部分。根据图 16-2 （ a）回答下面的问题：应用程序进程的页目录和页表一共占用了几个物理页？页框号分别是多少？映射用户地址空间（低 2G）的页表的页框号是多少？该页表有几个有效的 PTE，或者说有几个物理页用来装载应用程序的代码、数据和堆栈？页框号分别是多少？3.3查看应用程序进程和系统进程并发时的页目录和页表需要对 EOS应用程序进行一些修改：1. 结束之前的调试。2. 取消 EOSApp.c第 121行语句的注释（该行

5、语句会等待 10秒）。3. 按 F7生成修改后的 EOS应用程序项目。4. 按 F5启动调试。5.在“ Console-1 ”中会自动执行 EOSApp.exe，创建该应用程序进程。利用其等待 10秒的时间， 按 Ctrl+F2切换到“ Console-2 ”。2 / 6.6. 在“ Console-2 ”中输入命令“ mm”后按回车，会将系统进程的二级页表映射信息输出到虚拟机窗口和OS Lab的“输出” 窗口，输出内容如图16-2（ b）。注意，在图 16-2（ b）中添加了一些空行，方便与图 16-2（ a）比较。“ Console-1 ”中的应用程序在等待10秒后，又会输出和图16-2

6、（ a）一致的内容。7. 将“输出”窗口中的内容复制到一个文本文件中。控制台命令“mm”对应的源代码在EOS内核项目 ke/sysproc.c文件的 ConsoleCmdMemoryMap函数中（第 382行）。阅读这部分源代码后会发现，其与EOSApp.c文件中的源代码基本类似。结合图 16-2 （ a）和（ b）回答下面的问题：EOS启动后系统进程是一直运行的，所以当创建应用程序进程后，系统中就同时存在了两个进程，这两个进程是否有各自的页目录？在页目录映射的页表中，哪些是独占的，哪些是共享的？分析其中的原因。统计当应用程序进程和系统进程并发时，总共有多少物理页被占用？应用程序结束后，在“C

7、onsole-1 ”中再次输入命令“mm”，查看在没有应用程序进程时，系统进程的页目录和页表。将“输出”窗口中的内容复制到一个文本文件中。将输出的内容与图16-2 （ b）比较，思考为什么系统进程 （即内核地址空间）占用的物理页会减少？（提示： 创建应用程序进程时，EOS内核要为其创建PCB，应用程序结束时，内核要释放PCB占用的内存。）3.4查看应用程序进程并发时的页目录和页表需要对 EOS应用程序进行一些修改：1. 结束之前的调试。2. 取消 EOSApp.c第 201行语句的注释（该行语句会等待 10秒）。3. 按 F7生成修改后的 EOS应用程序项目。4. 按 F5启动调试。5.在“

8、Console-1 ”中会自动执行 EOSApp.exe，创建该应用程序进程。 利用其等待 10秒的时间， 按 Ctrl+F2切换到“ Console-2 ”。6.在“ Console-2 ”中输入“ eosapp ”后按回车，再执行一个EOSApp.exe。7.由 EOSApp.exe创建的两个并发进程会先后在各自的控制台和OS Lab“输出”窗口中，输出各自的二级页表映射信息。输出的内容如图16-3 。8. 将“输出”窗口中的内容复制到一个文本文件中。3 / 6.图 16-3：（a）应用程序进程1 的二级页表映射信息（ b）应用程序进程2 的二级页表映射信息结合图 16-3 （ a）和（

9、b）回答下面的问题：观察这两个进程的用户地址空间，可以得出结论：同一个应用程序创建的两个并发的进程，它们的用户虚拟地址空间完全相同， 而映射的物理页完全不同， 从而保证相同的行为 （执行过程） 可以在独立的空间内完成。假设进程 1的 0x41E和0x41F物理页保存了应用程序的可执行代码，由于可执行代码是不变的、只读的，现在假设优化过的 EOS允许进程 2共享进程 1的保存了可执行代码的物理页， 尝试结合图 16-3 写出此时进程 2用户地址空间的映射信息。并说明共享可执行代码的物理页能带来哪些好处。统计当两个应用程序进程并发时，总共有多少物理页被占用？有更多的进程同时运行呢？根据之前的操作方

10、式，尝试在更多的控制台中启动应用程序来验证自己的想法。 如果进程的数量足够多， 物理内存是否会用尽，如何解决该问题？3.5在二级页表中映射新申请的物理页下面通过编程的方式，从EOS操作系统内核中申请两个未用的物理页，将第一个物理页当作页表，映射基址为 0xE0000000的 4M虚拟地址空间， 然后将第二个物理页分别映射到基址为0xE0000000和 0xE0001000的 4K虚拟地址空间。从而验证下面的结论：虽然进程可以访问 4G虚拟地址空间， 但是只有当一个虚拟地址通过二级页表映射关系能够映射到实际的物理地址时，该虚拟地址才能够被访问，否则会触发异常。所有未用的物理页都是由EOS操作系统

11、内核统一管理的，使用时必须向内核申请。为虚拟地址映射物理页时，必须首先为页目录安装页表，然后再为页表安装物理页。并且只有在刷新快表4 / 6.后，对页目录和页表的更改才能生效。不同的虚拟地址可以映射相同的物理页，从而实现共享。首先验证第一个结论：1. 新建一个 EOS Kernel 项目。2. 从“项目管理器”打开 ke/sysproc.c 文件。3. 打开本实验文件夹中的 MapNewPage.c文件（将文件拖动到 OS Lab窗口中释放即可）。4. 在 sysproc.c 文件的 ConsoleCmdMemoryMap函数中找到 “关中断” 的代码行（第 413行），将 MapNewPag

12、e.c文件中的代码插入到“关中断”代码行的后面。5. 按 F7生成该内核项目。6. 按 F5启动调试。7. 在 EOS控制台中输入命令“ mm”后按回车。8. OS Lab 会弹出一个调试异常对话框，选择“是”调试异常。9.黄色箭头指向访问虚拟地址0xE0000000的代码行。由于该虚拟地址没有映射物理内存（图 16-2 和图 16-3中都未映射该虚拟地址），所以对该虚拟地址的访问会触发异常。10. 结束此次调试，然后删除或者注释会触发异常的该行代码。按照下面的步骤验证其它结论：1. 按 F7生成该内核项目。2. 按 F5启动调试。3. 在 EOS控制台中输入命令“ mm”后按回车。4. 在

13、OS Lab的“输出”窗口中查看执行的结果，并将“输出”窗口中的内容复制到一个文本文件中。结合插入的源代码和执行的结果理解上面的结论。注意，在代码中修改了虚拟地址0xE0000000 处的内存的值，然后从虚拟地址0xE0001000 处读取到了相同的值，原因是这两处虚拟地址映射到了相同的物理页。四、思考与练习1.观察之前输出的页目录和页表的映射关系，可以看到页目录的第0x300个 PDE映射的页框号就是页目录本身，说明页目录被复用为了页表。而恰恰就是这种映射关系决定了4K的页目录映射在虚拟地址空间的0xC0300000-0xC0300FFF,4M的页表映射在0xC0000000-0xC03FF

14、FFF。现在，假设修改了页目录， 使其第 0x100个 PDE映射的页框号是页目录本身，此时页目录和页表会映射在4G虚拟地址空间的什么位置呢？说明计算方法。2. 修改 EOSApp.c中的源代码，通过编程的方式统计并输出用户地址空间占用的内存数目。3. 修改 EOSApp.c中的源代码，通过编程的方式统计并输出页目录和页表的数目。注意页目录被复用为页表。4. 在 EOS启动时，软盘引导扇区被加载到从0x7C00开始的 512个字节的物理内存中，计算一下其所在的物理页框号，然后根据物理内存与虚拟内存的映射关系得到其所在的虚拟地址。修改EOSApp.c中的源代码，5 / 6.尝试将软盘引导扇区所在

15、虚拟地址的 512个字节值打印出来，与 boot.lst 文件中的指令字节码进行比较，验证计算的虚拟地址是否正确。5.既然所有 1024个页表（共 4M）映射在虚拟地址空间的0xC0000000-0xC03FFFFF，为什么不能从页表基址0xC0000000开始遍历，来查找有效的页表呢？而必须先在页目录中查找有效的页表呢？编写代码尝试一下，看看会有什么结果。6.学习 EOS操作系统内核统一管理未用物理页的方法（可以参考本书第6章的第 6.5 节）。尝试在本实验第3.5 节中 ConsoleCmdMemoryMap函数源代码的基础上进行修改，将申请到的物理页从二级页表映射中移除，并让内核回收这些物理页。7. 思考页式存储管理机制的优缺点。6 / 6