21 | 内存管理(下):为客户保密,项目组独享会议室封闭开发

上一节,我们讲了虚拟空间的布局。接下来,我们需要知道,如何将其映射成为物理地址呢?

你可能已经想到了,咱们前面讲x86 CPU的时候,讲过分段机制,咱们规划虚拟空间的时候,也是将空间分成多个段进行保存。

那就直接用分段机制呗。我们来看看分段机制的原理。

分段机制下的虚拟地址由两部分组成,段选择子段内偏移量。段选择子就保存在咱们前面讲过的段寄存器里面。段选择子里面最重要的是段号,用作段表的索引。段表里面保存的是这个段的基地址段的界限特权等级等。虚拟地址中的段内偏移量应该位于0和段界限之间。如果段内偏移量是合法的,就将段基地址加上段内偏移量得到物理内存地址。

例如,我们将上面的虚拟空间分成以下4个段,用0~3来编号。每个段在段表中有一个项,在物理空间中,段的排列如下图的右边所示。

如果要访问段2中偏移量600的虚拟地址,我们可以计算出物理地址为,段2基地址2000 + 偏移量600 = 2600。

多好的机制啊!我们来看看Linux是如何使用这个机制的。

在Linux里面,段表全称段描述符表(segment descriptors),放在全局描述符表GDT(Global Descriptor Table)里面,会有下面的宏来初始化段描述符表里面的表项。

#define GDT_ENTRY_INIT(flags, base, limit) { { { \
		.a = ((limit) & 0xffff) | (((base) & 0xffff) << 16), \
		.b = (((base) & 0xff0000) >> 16) | (((flags) & 0xf0ff) << 8) | \
			((limit) & 0xf0000) | ((base) & 0xff000000), \
	} } }

一个段表项由段基地址base、段界限limit,还有一些标识符组成。

DEFINE_PER_CPU_PAGE_ALIGNED(struct gdt_page, gdt_page) = { .gdt = {
#ifdef CONFIG_X86_64
	[GDT_ENTRY_KERNEL32_CS]		= GDT_ENTRY_INIT(0xc09b, 0, 0xfffff),
	[GDT_ENTRY_KERNEL_CS]		= GDT_ENTRY_INIT(0xa09b, 0, 0xfffff),
	[GDT_ENTRY_KERNEL_DS]		= GDT_ENTRY_INIT(0xc093, 0, 0xfffff),
	[GDT_ENTRY_DEFAULT_USER32_CS]	= GDT_ENTRY_INIT(0xc0fb, 0, 0xfffff),
	[GDT_ENTRY_DEFAULT_USER_DS]	= GDT_ENTRY_INIT(0xc0f3, 0, 0xfffff),
	[GDT_ENTRY_DEFAULT_USER_CS]	= GDT_ENTRY_INIT(0xa0fb, 0, 0xfffff),
#else
	[GDT_ENTRY_KERNEL_CS]		= GDT_ENTRY_INIT(0xc09a, 0, 0xfffff),
	[GDT_ENTRY_KERNEL_DS]		= GDT_ENTRY_INIT(0xc092, 0, 0xfffff),
	[GDT_ENTRY_DEFAULT_USER_CS]	= GDT_ENTRY_INIT(0xc0fa, 0, 0xfffff),
	[GDT_ENTRY_DEFAULT_USER_DS]	= GDT_ENTRY_INIT(0xc0f2, 0, 0xfffff),
......
#endif
} };
EXPORT_PER_CPU_SYMBOL_GPL(gdt_page);

这里面对于64位的和32位的,都定义了内核代码段、内核数据段、用户代码段和用户数据段。

另外,还会定义下面四个段选择子,指向上面的段描述符表项。这四个段选择子看着是不是有点眼熟?咱们讲内核初始化的时候,启动第一个用户态的进程,就是将这四个值赋值给段寄存器。

#define __KERNEL_CS			(GDT_ENTRY_KERNEL_CS*8)
#define __KERNEL_DS			(GDT_ENTRY_KERNEL_DS*8)
#define __USER_DS			(GDT_ENTRY_DEFAULT_USER_DS*8 + 3)
#define __USER_CS			(GDT_ENTRY_DEFAULT_USER_CS*8 + 3)

通过分析,我们发现,所有的段的起始地址都是一样的,都是0。这算哪门子分段嘛!所以,在Linux操作系统中,并没有使用到全部的分段功能。那分段是不是完全没有用处呢?分段可以做权限审核,例如用户态DPL是3,内核态DPL是0。当用户态试图访问内核态的时候,会因为权限不足而报错。

其实Linux倾向于另外一种从虚拟地址到物理地址的转换方式,称为分页(Paging)。

对于物理内存,操作系统把它分成一块一块大小相同的页,这样更方便管理,例如有的内存页面长时间不用了,可以暂时写到硬盘上,称为换出。一旦需要的时候,再加载进来,叫做换入。这样可以扩大可用物理内存的大小,提高物理内存的利用率。

这个换入和换出都是以页为单位的。页面的大小一般为4KB。为了能够定位和访问每个页,需要有个页表,保存每个页的起始地址,再加上在页内的偏移量,组成线性地址,就能对于内存中的每个位置进行访问了。

虚拟地址分为两部分,页号页内偏移。页号作为页表的索引,页表包含物理页每页所在物理内存的基地址。这个基地址与页内偏移的组合就形成了物理内存地址。

下面的图,举了一个简单的页表的例子,虚拟内存中的页通过页表映射为了物理内存中的页。

32位环境下,虚拟地址空间共4GB。如果分成4KB一个页,那就是1M个页。每个页表项需要4个字节来存储,那么整个4GB空间的映射就需要4MB的内存来存储映射表。如果每个进程都有自己的映射表,100个进程就需要400MB的内存。对于内核来讲,有点大了 。

页表中所有页表项必须提前建好,并且要求是连续的。如果不连续,就没有办法通过虚拟地址里面的页号找到对应的页表项了。

那怎么办呢?我们可以试着将页表再分页,4G的空间需要4M的页表来存储映射。我们把这4M分成1K(1024)个4K,每个4K又能放在一页里面,这样1K个4K就是1K个页,这1K个页也需要一个表进行管理,我们称为页目录表,这个页目录表里面有1K项,每项4个字节,页目录表大小也是4K。

页目录有1K项,用10位就可以表示访问页目录的哪一项。这一项其实对应的是一整页的页表项,也即4K的页表项。每个页表项也是4个字节,因而一整页的页表项是1K个。再用10位就可以表示访问页表项的哪一项,页表项中的一项对应的就是一个页,是存放数据的页,这个页的大小是4K,用12位可以定位这个页内的任何一个位置。

这样加起来正好32位,也就是用前10位定位到页目录表中的一项。将这一项对应的页表取出来共1k项,再用中间10位定位到页表中的一项,将这一项对应的存放数据的页取出来,再用最后12位定位到页中的具体位置访问数据。

你可能会问,如果这样的话,映射4GB地址空间就需要4MB+4KB的内存,这样不是更大了吗? 当然如果页是满的,当时是更大了,但是,我们往往不会为一个进程分配那么多内存。

比如说,上面图中,我们假设只给这个进程分配了一个数据页。如果只使用页表,也需要完整的1M个页表项共4M的内存,但是如果使用了页目录,页目录需要1K个全部分配,占用内存4K,但是里面只有一项使用了。到了页表项,只需要分配能够管理那个数据页的页表项页就可以了,也就是说,最多4K,这样内存就节省多了。

当然对于64位的系统,两级肯定不够了,就变成了四级目录,分别是全局页目录项PGD(Page Global Directory)、上层页目录项PUD(Page Upper Directory)、中间页目录项PMD(Page Middle Directory)和页表项PTE(Page Table Entry)。

总结时刻

这一节我们讲了分段机制、分页机制以及从虚拟地址到物理地址的映射方式。总结一下这两节,我们可以把内存管理系统精细化为下面三件事情:

  • 第一,虚拟内存空间的管理,将虚拟内存分成大小相等的页;

  • 第二,物理内存的管理,将物理内存分成大小相等的页;

  • 第三,内存映射,将虚拟内存页和物理内存页映射起来,并且在内存紧张的时候可以换出到硬盘中。

课堂练习

这一节我们说一个页的大小为4K,有时候我们需要为应用配置大页(HugePage)。请你查一下大页的大小及配置方法,咱们后面会用到。

欢迎留言和我分享你的疑惑和见解,也欢迎你收藏本节内容,反复研读。你也可以把今天的内容分享给你的朋友,和他一起学习、进步。

精选留言

  • geraltlaush

    2019-05-15 07:44:09

    分页机制本质上来说就是类似于linux文件系统的目录管理一样,页目录项和页表项相当于根目录和上级目录,页内便宜量就是相对路径,绝对路径就是整个32位地址,分布式存储系统也是采用的类似的机制,先用元数据存储前面的路径,再用块内偏移定位到具体文件,感觉道理都差不多
    作者回复

    是的

    2019-09-05 10:33:53

  • why

    2019-05-16 17:00:54

    - 内存管理(下)
    - 虚拟内存地址到物理内存地址的映射
    - 分段
    - 虚拟地址 = 段选择子(段寄存器) + 段内偏移量
    - 段选择子 = 段号(段表索引) + 标识位
    - 段表 = 物理基地址 + 段界限(偏移量范围) + 特权等级
    - Linux 分段实现
    - 段表称为段描述符表, 放在全局标识符表中
    - Linux 将段基地址都初始化为 0, 不用于地址映射
    - Linux 分段功能主要用于权限检查
    - Linux 通过分页实现映射
    - 物理内存被换分为大小固定(4KB)的页, 物理页可在内存与硬盘间换出/换入
    - 页表 = 虚拟页号 + 物理页号; 用于定位页
    - 虚拟地址 = 虚拟页号 + 页内偏移
    - 若采用单页表, 32位系统中一个页表将有 1M 页表项, 占用 4MB(每项 4B)
    - Linux 32位系统采用两级页表: 页表目录(1K项, 10bit) + 页表(1K项, 10bit)(页大小(4KB, 12bit))
    - 映射 4GB 内存理论需要 1K 个页表目录项 + 1K\*1K=1M 页表项, 将占用 4KB+4MB 空间
    - 因为完整的页表目录可以满足所有地址的查询, 因此页表只需在对应地址有内存分配时才生成;
    - 64 为系统采用 4 级页表
  • 清河

    2020-08-28 17:04:31

    https://jishuin.proginn.com/p/763bfbd248c0
    这篇文章看起来更容易理解
  • 栋能

    2019-07-20 17:16:53

    64位Linux机器,4KB页大小,那虚拟地址组成应该是:22位PGD、10位PUD、10位PMD、10位PTE、12位页偏移地址
    作者回复

    由于x86_64处理器硬件限制。x86_64处理器地址线只有48条,故而导致硬件要求传入的地址48位到63位地址必须相同。 4K页面下, 48位线性地址分为5段,位宽度分别是9、9、9、12。映射的方法为页表查找。

    2019-08-21 11:21:16

  • 崔伟协

    2019-05-15 16:54:32

    分页,分段机制的优劣在于哪儿呢,为什么有分页分段
    作者回复

    都是硬件的机制,操作系统作为软件要用硬件机制。文章里面写了优劣势了。分段容易碎片,不容易换出。

    2019-05-17 12:41:56

  • kkxue

    2019-06-03 23:32:02

    [root@openstack-rocky ~]# getconf PAGE_SIZE
    4096
    [root@openstack-rocky ~]# cat /sys/kernel/mm/hugepages/hugepages-2048kB/nr_hugepages
    0
    [root@openstack-rocky ~]# grep Huge /proc/meminfo
    AnonHugePages: 612352 kB
    HugePages_Total: 0
    HugePages_Free: 0
    HugePages_Rsvd: 0
    HugePages_Surp: 0
    Hugepagesize: 2048 kB
    [root@openstack-rocky ~]# free -g
    total used free shared buff/cache available
    Mem: 5 4 0 0 0 0
    Swap: 5 0 5
    [root@openstack-rocky ~]# echo 1024 > /sys/kernel/mm/hugepages/hugepages-2048kB/nr_hugepages
    [root@openstack-rocky ~]# free -g
    total used free shared buff/cache available
    Mem: 5 5 0 0 0 0
    Swap: 5 0 5
    [root@openstack-rocky ~]# grep Huge /proc/meminfo
    AnonHugePages: 618496 kB
    HugePages_Total: 242
    HugePages_Free: 242
    HugePages_Rsvd: 0
    HugePages_Surp: 0
    Hugepagesize: 2048 kB
  • Helios

    2019-05-15 13:25:25

    请问老师为什么一个表项用4个字节去存储呢
    作者回复

    规定,可以去查一下表项的结构,太细节了,所以这里没有提

    2019-05-15 13:52:49

  • 淤白

    2020-01-28 15:18:40

    通过本篇内容,学习到在内存空间不足的情况下,使用索引可以有效的减少内存消耗,如果一层索引消耗还是无法接受,可以生成多级索引,除了第一层是提前创建,其余索引通过懒加载的方式创建出来。

    虚拟内存和物理内存中的管理,就是将内存空间划分成一个个大小相等的页,并对其做多级索引。在将虚拟内存和物理内存映射起来时,如果内存吃紧,可以将部分内存页面换出到磁盘上。
  • @许还真

    2021-03-11 08:42:45

    表设计,听起来有点像跳表。
  • 蚂蚁内推+v

    2020-03-19 23:36:17

    老师您好,对于linux的虚拟内存和实际内存,我有个问题想咨询,一般我们用top命令查看当前服务器进程状态的时候,进程内存相关的数据有virt和res。
    1、请问这virt是实际使用的虚拟内存吗?
    2、virt=res+swap吗?
    3、没什么一般virt比res大,但是swap的使用量为0,virt多的那部分内存是哪里?
  • garlic

    2020-01-11 07:52:04

    处理器体系结构支持多重页面大小,操作系统可以根据需要进行相关设置,Linux可以通过hugepage,结合处理器支持页面大小设置多种页面大小,相关笔记: https://garlicspace.com/2020/01/10/%e5%86%85%e5%ad%98%e7%ae%a1%e7%90%86-%e9%a1%b5%e9%9d%a2%e5%a4%a7%e5%b0%8f/
    作者回复

    是的,Hugepage在优化内存的时候,经常使用,例如虚拟机或者DPDK使用Hugepage

    2020-01-12 18:01:58

  • lcf枫

    2019-11-13 10:12:23

    老师,这里的段和页是个什么关系,怎么关联起来?
  • 最爱冰美式

    2020-03-17 08:38:37

    这样 1K 个 4K 就是 1K 个页感觉和绕口令似的呢,关键是还没看懂 😂
  • 饭粒

    2019-06-27 22:51:37

    32位系统的两级页表那“ 映射 4GB 地址空间就需要 4MB+4KB 的内存”,怎么算的 4MB+4KB ?不太明白。
    作者回复

    第一级4M,第二级4K

    2019-09-03 16:52:47

  • 小松松

    2019-05-20 12:02:09

    请问一下,Linux在哪些管理上使用的分段,哪些情况使用的是分页呢? 还是说现代操作系统都已经倾向于使用分页来管理了。
    作者回复

    分段仅用于权限

    2019-09-04 23:18:53

  • 有铭

    2019-05-15 09:54:40

    为什么页的默认大小是4KB,这是以什么理由定下来的,为什么不是2KB或者8KB呢
    作者回复

    历史因素吧

    2019-09-05 10:31:11

  • 喜剧。

    2021-05-12 08:37:55

    内存管理,本质上是虚拟地址到物理地址映射关系的管理。管理这个关系,我们要注意自身的管理成本,这样我们将内存分页,再对页进行管理。如果只分一层,维护起来比较麻烦。我们再往上加一层,弄个页目录,我们只需要维护好页目录,有数据的时候再加个页表项数据,这样就比较轻松了。
  • 吴钩

    2021-04-19 17:08:27

    用了一个小时才想明白,之所以单层的页表空间利用率低,因为必须一次性分配出4mb,这是因为页表是个数组,靠数组下标(偏移量)定位表项!
  • ABC

    2020-10-09 19:40:51

    原文:“如果只使用页表,也需要完整的 1M 个页表项共 4M 的内存,但是如果使用了页目录,页目录需要 1K 个全部分配,占用内存 4K,但是里面只有一项使用了。到了页表项,只需要分配能够管理那个数据页的页表项页就可以了,也就是说,最多 4K,这样内存就节省多了。“
    疑问:如果使用了页目录,页目录里面为何只有一项使用了?不应该是根据实际情况可能有多项被使用么?
  • k先生

    2020-01-07 17:59:08

    老师,现在不都是用倒排页表了吗?还用多级页表吗?
    作者回复

    本课程主要解析x86和x86_64

    2020-01-12 19:02:04