虚拟页式存储管理
1 分页机制
在虚拟内存中，页表是个映射表的概念, 即从进程能理解的线性地址(linear address)映射到存储器上的物理地址(phisical address).
很显然，这个页表是需要常驻内存的东西, 以应对频繁的查询映射需要(实际上，现代支持VM的处理器都有一个叫TLB的硬件级页表缓存部件，本文不讨论）。
1.1 为什么使用多级页表来完成映射
但是为什么要使用多级页表来完成映射呢?
用来将虚拟地址映射到物理地址的数据结构称为页表, 实现两个地址空间的关联最容易的方式是使用数组, 对虚拟地址空间中的每一页, 都分配一个数组项. 该数组指向与之关联的页帧, 但这会引发一个问题, 例如, IA-32体系结构使用4KB大小的页, 在虚拟地址空间为4GB的前提下, 则需要包含100万项的页表. 这个问题在64位体系结构下, 情况会更加糟糕. 而每个进程都需要自身的页表, 这回导致系统中大量的所有内存都用来保存页表.
设想一个典型的32位的X86系统，它的虚拟内存用户空间(user space)大小为3G, 并且典型的一个页表项(page table entry, pte)大小为4 bytes，每一个页(page)大小为4k bytes。那么这3G空间一共有(3G/4k=)786432个页面，每个页面需要一个pte来保存映射信息，这样一共需要786432个pte!
如何存储这些信息呢？一个直观的做法是用数组来存储，这样每个页能存储(4k/4=)1K个，这样一共需要(786432/1k=)768个连续的物理页面(phsical page)。而且，这只是一个进程，如果要存放所有N个进程，这个数目还要乘上N! 这是个巨大的数目，哪怕内存能提供这样数量的空间，要找到连续768个连续的物理页面在系统运行一段时间后碎片化的情况下，也是不现实的。
为减少页表的大小并容许忽略不需要的区域, 计算机体系结构的涉及会将虚拟地址分成多个部分. 同时虚拟地址空间的大部分们区域都没有使用, 因而页没有关联到页帧, 那么就可以使用功能相同但内存用量少的多的模型: 多级页表
但是新的问题来了, 到底采用几级页表合适呢?
1.2 32位系统中2级页表
从80386开始, intel处理器的分页单元是4KB的页, 32位的地址空间被分为3部分
单元
描述
页目录表Directory 最高10位
页中间表Table 中间10位
页内偏移 最低12位
即页表被划分为页目录表Directory和页中间表Tabl两个部分
此种情况下, 线性地址的转换分为两步完成.
第一步, 基于两级转换表(页目录表和页中间表), 最终查找到地址所在的页帧
第二步, 基于偏移, 在所在的页帧中查找到对应偏移的物理地址
使用这种二级页表可以有效的减少每个进程页表所需的RAM的数量. 如果使用简单的一级页表, 那将需要高达220个页表, 假设每项4B, 则共需要占用220?4B=4MB的RAM来表示每个进程的页表. 当然我们并不需要映射所有的线性地址空间(32位机器上线性地址空间为4GB), 内核通常只为进程实际使用的那些虚拟内存区请求页表来减少内存使用量.
1.3 64位系统中的分页
正常来说, 对于32位的系统两级页表已经足够了, 但是对于64位系统的计算机, 这远远不够.
首先假设一个大小为4KB的标准页. 因为1KB覆盖210个地址的范围, 4KB覆盖212个地址, 所以offset字段需要12位.
这样线性地址空间就剩下64-12=52位分配给页中间表Table和页目录表Directory. 如果我们现在决定仅仅使用64位中的48位来寻址(这个限制其实已经足够了, 2^48=256TB, 即可达到256TB的寻址空间). 剩下的48-12=36位被分配给Table和Directory字段. 即使我们现在决定位两个字段各预留18位, 那么每个进程的页目录和页表都包含218个项, 即超过256000个项.
基于这个原因, 所有64位处理器的硬件分页系统都使用了额外的分页级别. 使用的级别取决于处理器的类型
平台名称
页大小
寻址所使用的位数
分页级别数
线性地址分级
alpha 8KB 43 3 10 + 10 + 10 + 13
ia64 4KB 39 3 9 + 9 + 9 + 12
ppc64 4KB 41 3 10 + 10 + 9 + 12
sh64 4KB 41 3 10 + 10 + 9 + 12
x86_64 4KB 48 4 9 + 9 + 9 + 9 + 12
② 页式虚拟存储管理,过小的页会引起什么问题
会引起内存变小。在页式虚拟存储管理系统中，页面的大小是由计算机系统的地址结构所决定的，一般由软硬件共同决定。对于某一种系统一般采用一种大小穗简的页面，也有部分现代操芦皮作系统采用双页面系统的。在确定地址结构时，若选择的页面较小，一方面可使内碎片减小，并减少了内碎猜哗裤片的总空间，有利于提高内存利用率。另一方面，也会使每个进程要求较多的页面，从而导致页表过长，占用大量内存。此外还会降低页面换进换出的效率。
③ 在页式虚拟存贮器中，什么叫页面失效什么叫页面争用什么时候两者同时发生
页面失效是该页未装入主存，需要从辅存中调页。页面争用(冲突)是两个以上的虚页想要进入主存中同一页面位置的现象。页面失效不一定发生页面冲突，页面争用一定由页面失效引起。
④ 采用页式虚拟存储管理方式页大小为8KB，主存块大小为64B，为什么物理地址的页内偏移量不等于主存块大小
物理地址的页偏移量等于对应虚拟地址的页偏移量，虚拟地址的页偏移量与页大小有关，这里页大小8KB，2的13次方，所以页偏移量为13位。
⑤ 什么是LRU测试请知道的告诉一下
LRU是Least Recently Used的缩写，即最近最少使用页面置换算法，是为虚拟页式存储管理服务的。 关 于操作系统的内存管理，如何节省利用容量不大的内存为最多的进程提供资源，一直是研究的重要方向。而内存的虚拟存储管理，是现在最通用，最成功的方式—— 在内存有限的情况下，扩展一部分外存作为虚拟内存，真正的内存只存储当前运行时所用得到信息。这无疑极大地扩充了内存的功能，极大地提高了计算机的并发 度。虚拟页式存储管理，则是将进程所需空间划分为多个页面，内存中只存放当前所需页面，其余页面放入外存的管理方式。 然而，有利就有弊，虚拟页式存储管理减少了进程所需的内存空间，却也带来了运行时间变长这一缺点：进程运行过程中，不可避免地要把在外存中存放的一些信息和 内存中已有的进行交换，由于外存的低速，这一步骤所花费的时间不可忽略。因而，采取尽量好的算法以减少读取外存的次数，也是相当有意义的事情。 对 于虚拟页式存储，内外存信息的替换是以页面为单位进行的——当需要一个放在外存的页面时，把它调入内存，同时为了保持原有空间的大小，还要把一个内存中页 面调出至外存。自然，这种调动越少，进程执行的效率也就越高。那么，把哪个页面调出去可以达到调动尽量少的目的？我们需要一个算法。 自然，达到这样一种情形的算法是最理想的了——每次调换出的页面是所有内存页面中最迟将被使用的——这可以最大限度的推迟页面调换，这种算法，被称为理想页面置换算法。可惜的是，这种算法是无法实现的。 为了尽量减少与理想算法的差距，产生了各种精妙的算法，最近最少使用页面置换算法便是其中一个。LRU算法的提出，是基于这样一个事实：在前面几条指令中使用频繁的页面很可能在后面的几条指令中频繁使用。反过来说，已经很久没有使用的页面很可能在未来较长的一段时间内不会被用到。这个，就是着名的局部性原理——比内存速度还要快的cache，也是基于同样的原理运行的。因此，我们只需要在每次调换时，找到最近最少使用的那个页面调出内存。这就是LRU算法的全部内容。 如何用具体的数据结构来实现这个算法？ 首先，最容易想到，也最简单的方法：计时法。给页表中的每一页增加一个域，专门用来存放计时标志，用来记录该页面自上次被访问以来所经历的时间。页面每被访问一次，计时清0。要装入新页时，从内存的页面中选出时间最长的一页，调出，同时把各页的计时标志全部清0，重新开始计时。 计时法可以稍作改变，成为计数法：页面被访问，计数标志清0，其余所有内存页面计数器加1；要装入新页时，选出计数最大的一页调出，同时所有计数器清0。 这两种方法确实很简单，但运行效率却不尽如人意。每个时刻，或是每调用一个页面，就需要对内存中所有页面的访问情况进行记录和更新，麻烦且开销相当大。 另一种实现的方法：链表法。 操作系统为每个进程维护一条链表，链表的每个结点记录一张页面的地址。调用一次页面，则把该页面的结点从链中取出，放到链尾；要装入新页，则把链头的页面调出，同时生成调入页面的结点，放到链尾。 链表法可看作简单计时/计数法的改良，维护一个链表，自然要比维护所有页面标志要简单和轻松。可是，这并没有在数量级上改变算法的时间复杂度，每调用一个页面，都要在链表中搜寻对应结点并放至链尾的工作量并不算小。 以上是单纯使用软件实现的算法。不过，如果能有特殊的硬件帮忙，我们可以有更有效率的算法。 首先，如果硬件有一个64位的计数器，每条指令执行完后自动加1。在每个页表项里添加一个域，用于存放计数器的值。进程运行，每次访问页面的时候，都把计数器的值保存在被访问页面的页表项中。一旦发生缺页，操作系统检查页表中所有的计数器的值以找出最小的一个，那这一页就是最久未使用的页面，调出即可。 其次，另外一个矩阵算法：在一个有n个页框的机器中，LRU硬件可以维持一个n*n的矩阵，开始时所有位都是0。访问到第k页时，硬件把k行的位全设为1，之后再把k列的位置设为0。容易证明，在任意时候，二进制值最小的行即为最久未使用的页面，当调换页面时，将其调出。 以上的两种算法，无疑都要比纯粹的软件算法方便且快捷。每次页面访问之后的操作——保存计数器值和设置k行k列的值，时间复杂度都是O(1)量级，与纯软件算法不可同日而语。 那是否软件算法就毫无用处？当然不是，硬件算法有它致命的缺陷，那就是需要硬件的支持才能运行。如果机器上恰好有所需硬件，那无疑是再好不过；反之，若机器上没有这种硬件条件，我们也只能无奈地抛弃硬件算法，转而选取相对麻烦的软件算法了。 最后，让我们来谈论一下LRU算 法。首先，这是一个相当好的算法，它是理想算法很好的近似。在计算机系统中应用广泛的局部性原理给它打造了坚实的理论基础，而在实际运用中，这一算法也被 证明拥有极高的性能。在大规模的程序运行中，它产生的缺页中断次数已很接近理想算法。或许我们还能找到更好的算法，但我想，得到的收益与付出的代价恐怕就 不成比例了。当然，LRU算法的缺点在于实现方法的不足——效率高的硬件算法通常在大多数机器上无法运行，而软件算法明显有太多的开销。与之相对的，FIFO算法，和与LRU相似的NRU算法，性能尽管不是最好，却更容易实现。所以，找到一个优秀的算法来实现LRU，就是一个非常有意义的问题。
希望采纳
⑥ 求页式虚拟存储技术的原理。
虚拟存储器是根据程序的逻辑地址转换来的，也称线性地址空间。一般每个进程，甚至每个段都有一个，以32位为例，则每个最大可达4G。 而主存目前一般为百M。因此程序中所指的存储单元并不能都放到主存中，也就是并不是每个程序所用的存储单元，都有具体的物理的存储器单元与之对应。 但由于程序的两个局部性原理，在一个时刻，程序只在一个比较小的范围内运行。所以我们把程序可能用到的整个存储空间分成一个个相同大小的页(按页管理硬件上容易实现)，只把其中的一些页放在主存中，而其它的页则等需要时再建，或放在辅存(磁盘)中。同时建立一个页表，对应于每一页，如果该页在主存中，则页表记录它在主存中的地址；如果不在主存中，则在页表上作不在主存的标记。 这样，当程序需要调用某个存储单元的内容时，先根据它的线性地址，算出其所在的页。查页表，看是不是在主存中？如果在，则直接存取。如果查到页表上是不在的标记，那就是一个page fault。要把主存中的某一页(LRU策略)换到磁盘上，把要访问的那个单元所在的页调入主存，再进行存取。 就象一个预计有一万学生的学校，理论上每个学生都应有一个位子上课(一万个虚拟位子)，而学校只有一千个(物理)位子。但实际上，学校也不会一万个人同时上课，只要让上课的同学有位子(在主存中)，而其它同学只要留下联系方法能找到就好。为了降低管理的复杂性，我们采用按学号分班(页)管理。每个班要么一起上课(主存)，要么一起呆在寝室(磁盘)。而在学校保留一个动态表(页表)表明每个班在哪儿(物理地址)上课，或者没上课(不在主存)。现在假设我们想按学号找一个同学，而且是女同学，只能在教室说话，呵呵。那么： 先算出来是哪个班的，查动态表，看该班是否在教室。在，直接按位置找到(hit)；不在(page fault)，要先找个不上课的班赶回寝室，把要找女生所在的班调到教室，再按位置找那个同学。 动态表(页表)的大小＝表项数＊每个表项所需的位数。 表项数＝虚拟班数＝虚拟人数(虚拟地址空间)/每班人数(每页大小) 每个表项的位数＝Log(教室数)+适当控制位数
麻烦采纳，谢谢!