在64位机中，如果为每个进程保持一个页表，则会占用较大的内存空间，请设计一种能有效降低内存占用率的_百度问一问

发布网友发布时间：2022-04-29 18:29

共1个回答

热心网友时间：2023-10-03 05:55

摘要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，这样提高了查找速度。嗯嗯