在64位机中,如果为每个进程保持一个页表,则会占用较大的内存空间,请设计一种能有效降低内存占用率的页表方式,并说明其工作原理

1个回答
展开全部
摘要 64位计算机中,如果页面大小为4KB,那么64位寻址空间需要252个页表项。假设每个页表项大小为8B,那么需要30PB的空间,在目前计算机发展阶段显然是不现实的
咨询记录 · 回答于2021-11-13
在64位机中,如果为每个进程保持一个页表,则会占用较大的内存空间,请设计一种能有效降低内存占用率的页表方式,并说明其工作原理
64位计算机中,如果页面大小为4KB,那么64位寻址空间需要252个页表项。假设每个页表项大小为8B,那么需要30PB的空间,在目前计算机发展阶段显然是不现实的
倒排页表是一种解决方案,正如其名所揭示的:普通的页表是将虚地址映射成物理地址,提供的是将页号(page number)转化为页框号(page frame number)的对应;这个转化由MMU完成;而倒排页表正相反,提供的是将页框号转化为页号的对应。页框号是实际内存的大小/页面大小,因此1GB内存只需要262,144个项即可,远远小于252这个数字。
个人认为,这个解决思路的妙处在于:32位下,页表项总和比较少,至多两级页表也已够用;而64位下,内存的大小(也即物理地址空间)与寻址空间(虚地址空间)相比反而显得小了,这样干脆来个倒转,不失为一个很好的方法。当然这种解法虽然节约了大量的存储空间,但是内存管理中需要的是将虚地址转化成物理地址的机制,而不是正相反啊?这种映射是单向的,总不能每次转化都把这个表遍历一次吧?那样做的开销实在是太大了。一种解决方法是使用TLB,但是TLB也有失效(miss)的时候,这时还是需要进行查找。一个可行的方法是将所有用到的虚地址hash掉,形成一个hash表来加速查找,同样哈希值的虚地址形成一个链。如果hash表的槽数与物理内存的页框数一样多,那么哈希表各表项平均长度为1,这样提高了查找速度。
嗯嗯
下载百度知道APP,抢鲜体验
使用百度知道APP,立即抢鲜体验。你的手机镜头里或许有别人想知道的答案。
扫描二维码下载
×

类别

我们会通过消息、邮箱等方式尽快将举报结果通知您。

说明

0/200

提交
取消