确定虚拟内存的页表大小

Joh*_*n_D 20 memory paging virtual-memory page-tables

考虑具有38位虚拟字节地址,1KB页面和512 MB物理内存的虚拟内存系统.假设有效,保护,脏和使用位总共占用4位,并且所有虚拟页面都在使用中,则本机上每个进程的页表总大小是多少?(假设磁盘地址未存储在页表中.)

pax*_*blo 30

好吧,如果问题只是"页面表的大小是多少?" 无论它是否适合物理内存,都可以这样计算答案:

第一个物理记忆.有512K页的物理内存(512M/1K).这需要19位来表示每个页面.将其添加到4位会计信息中,您将得到23位.

现在虚拟内存.使用38位地址空间和10位(1K)页面大小,页面表中需要2 28个条目.

因此,每个23位的2 28页表项是6,174,015,488位或736M.

这是每个进程的单级VM子系统所需的最大大小.

现在很明显,如果你只有512M的物理内存,那么它就无法运行,所以你有两个选择.

  1. 您可以减少物理页面的数量.例如,只允许一半的内存进行分页,保持另一半驻留.这将为每个条目节省一点,但不足以产生影响.

  2. 如果可能,请增加页面大小.38位地址空间上的1K页面是非常粗糙的页表的原因.例如,我认为'386,其32位地址空间,使用4K页面.这将导致百万页表条目,远远少于此处所需的2.6亿.

  3. 去多层次.更高级但它基本上意味着页表本身受到分页.您必须将第一级页表保持在物理内存中,但第二级可以根据需要进出.这将大大降低物理要求,但代价是速度,因为可能会出现两个级别的页面错误以获得实际的进程页面(一个用于辅助分页表,一个用于进程页面).


让我们看一下选项3.

如果我们允许主要分页表使用32M,并且每个条目给出4个字节(32位:只需要23个,但我们可以在这里进行求效),这将允许8,388,608个页面用于辅助页面表.

由于每个辅助页面表页面都是1K长(允许我们以每个4字节存储256个辅助页面表项),因此我们可以处理总共2,147,483,648个虚拟页面.

这将允许8,192个完全加载(即,使用它们的整个28位地址空间)进程并排运行,假设您有一大块磁盘空间来存储非驻留页面.

现在很明显,主要的分页表(以及VM子系统,可能是操作系统其余部分的一大部分)必须始终保持驻留状态.您不能允许页面输出其中一个主页面,因为您可能需要该页面才能将其重新输入:-)

但是,对于主要分页表,512M的常驻成本仅为32M,远远优于736M的(至少一个完全加载过程).


小智 9

页表的大小=页表项的总数*页表项的大小

第1步:在页面表中找到参考号:

no of page table entries=virtual address space/page size

=2^38/2^10=2^28
Run Code Online (Sandbox Code Playgroud)

所以页表中有2 ^ 28个条目

第2步:没有物理记忆中的框架:

no of frames in the physical memory=(512*1024*1024)/(1*1024)=524288=2^19

所以我们需要19 bits和额外4 bits的有效,保护,脏和使用位总共23位= 2.875字节

size of the page table=(2^28)*2.875=771751936B=736MB
Run Code Online (Sandbox Code Playgroud)