【操作系统/OS笔记05】非连续内存分配:分段、分页、页表
本次笔记内容:
4.1 非连续内存分配:分段
4.2 非连续内存分配:分页
4.3 非连续内存分配:页表
文章目录
为什么需要非连续内存分配
连续分配有碎片等缺点。
非连续分配的优劣
优点:
- 一个程序的物理地址空间是非连续的;
- 更好的内存利用和管理;
- 允许共享代码与数据(共享库etc.);
- 支持动态加载和动态链接。
缺点:
- 如何建立虚拟地址和物理地址之间的转换
- 软件方案(开销巨大)
- 硬件方案(主要考虑的方案)
**硬件方案: **分段、分页。
分段(segment)
根据程序的段的性质,分离出来管理。
堆、运行栈、程序数据、程序text段分开管理,确保了效率、安全问题。
分段技术是一种映射。使用 硬件支持 来寻址,是一种较好方案。
分段寻址方案
s: segment number,段号;
addr: address,地址。
x86为段寄存器+地址寄存器实现方案。
上图中,左上角应用程序P通过CPU执行每条指令;CPU去寻址,这里采用单地址实现方案。段号保存在段表 (存储:逻辑地址与物理地址映射关系;每个段起始地址、长度限制)里,段号决定段表中的索引。段表是操作系统在寻址之前就建立好的。
段表如何建立在实验部分展开讲解。
分页(paging)
分页为较为常用方式。分页机制中,“段”的尺寸不可变,即为页。
基本规定
- 划分物理内存至固定大小的帧:大小是2的幂,e.g.,512,4096,8192。
- 划分逻辑地址空间至相同大小的页:大小是2的幂,e.g.,512,4096,8192。
- 建立方案:转换逻辑地址为物理地址(pages to frames)
- 页表
- MMU/TLB
帧(Frame)
物理内存被分割为大小相等的帧。帧存在帧号(frame number)与偏移(offset),相当于段中的段号与偏移。 帧号占了F这么多位,本身大小占了S这么多位。
上图示例中,(f,o)=(3,6),分别代表段号与本身所表示值。
思考(不一定对): 如果f=1(第一个页),o=3,则物理地址为29+32
9
+3。物理地址的1到16为是倒着的,则物理地址代表本物理内存存在元素的所在的最大一位。则对于(1,3),是填满第一页的1到3位,物理地址指向第3位。
页
逻辑地址中,用页表示。
在页中, 页号大小可能不等于帧号大小,但是偏移大小一定相等。
有了页号,查出帧号是多少。(p,o)→(f,o)。页表由操作系统建立。
分页机制,每页偏移大小固定,没有分段中存在的异常问题。一般来讲,逻辑地址空间大于物理内存地址空间,会产生问题,解决办法在虚拟内存中讨论。
页表
页表其实是一个大数组。
每个运行的程序都有一个页表。
上图中可以看到,页表项中存在一些bit,用于表示页的性质,如该页是否真实存在等等。
resident bit(驻留位),1代表页存在;Frame num是00100,对应物理地址f是4。
问题:
-
访问一个内存单元需要2次访问(空间开销大)。
- 一次用于获取页表项;
- 一次用于访问数据。
-
eg. 64位机器如果每页1024字节,那么一个页表大小是264/1024=2542 64/1024=2 54,过大。如果这样,计算机连一个页表都存不下。
-
并且,CPU的cache很小(几M),放不下多个应用程序的多个列表。
-
如何解决这些问题?
- 缓存(Caching);
- 间接(Indirection)访问。
TLB
常用页放在TLB中,直接映射到物理地址,也避免了对内存中页表的访问。如果TLB访问不到(TLB miss),CPU回去查页表。TLB缺失不会很大,因为写程序时,尽量保证了访问的局部性。
二级、多级页表
一级页表中不存在的索引,二级页表中也没有必要存在,因此节省了空间。
在这里插入图片描述
多级页表中,存在“树”状关系。像64位系统中,使用5级页表进行存储。 尽管访问级数越高,时间开销越大,但是节省了空间。而时间的开销又可以通过TLB机制缓解。
反向页表(inverted page table)
- 有大地址空间(64-bits,64位寻址空间),前向映射页表变得繁琐(如5级页表)。
- 不是让页表与逻辑地址空间的大小相对应,而是让页表与物理地址空间的大小相对应。
- 逻辑(虚拟)地址空间增长速度快于物理地址空间。
因此,以物理页的页帧号作为index,来查找逻辑页的页号。
办法一:基于页寄存器(Page Registers)的方案
寄存器中,以帧号为索引。寄存器大小只与物理地址有关。占的空间很少。
页寄存器一个例子:
-
物理内存大小:4096×4096=4K×4KB=16MB4096×4096=4K×4KB=16MB
-
页面大小:4096bytes=4KB4096bytes=4KB
-
页帧数:4096=4K4096=4K
-
页寄存器使用的空间(假设8 bytes/register):8×4096=32Kbytes8×4096=32Kbytes
-
页寄存器带来的额外开销:32K/16M=0.2%32K/16M=0.2%
-
虚拟内存大小:任意
但是在查找时,是根据Page number来查找Frame number。因此,页寄存器该如何查找?
基于关联内存(associative memory)的方案
关联存储器虽然解决了查找问题,但是设计复杂,需要放到CPU中(放到内存中存在访问开销问题),开销代价巨大。
基于哈希(hash)查找的方案
哈希计算一般使用硬件辅助计算加速。加入PID(程序ID)参数及哈希规则,有效缓解映射开销。
- 存在哈希碰撞问题,需要使用PID缓解这种冲突;
- 反向页表还是要放到内存中,还是需要TLB把其缓存起来。
- 这种机制(反向页表、不受制于虚拟地址空间限制)在高端CPU中才存在。