内存映射：小块内存申请brk和申请大块内存的Mmap分析

本文为内存部分最后一篇，介绍内存映射。内存映射不仅是物理内存和虚拟内存间的映射，也包括将文件中的内容映射到虚拟内存空间。这个时候，访问内存空间就能够访问到文件里面的数据。而仅有物理内存和虚拟内存的映射，是一种特殊情况。本文首先分析用户态在堆中申请小块内存的brk和申请大块内存的mmap，之后会分析内核态的内存映射机制vmalloc，kmap_atomic，swapper_pg_dir以及内核态缺页异常。

用户态调用malloc()会分配堆内存空间，而实际上则是完成了一次用户态的内存映射，根据分配空间的大小，内存映射对应的系统调用主要有brk()和mmap()(当然我们也可以直接调用mmap()来映射文件)。对小块内存（小于 128K），C 标准库使用 brk() 来分配，也就是通过移动堆顶的位置来分配内存。这些内存释放后并不会立刻归还系统，而是被缓存起来，这样就可以重复使用。而大块内存（大于 128K），则直接使用内存映射 mmap() 来分配，也就是在文件映射段找一块空闲内存分配出去。这两种方式，自然各有优缺点。

brk()方式的缓存，可以减少缺页异常的发生，提高内存访问效率。不过，由于这些内存没有归还系统，在内存工作繁忙时，频繁的内存分配和释放会造成内存碎片。

mmap() 方式分配的内存，会在释放时直接归还系统，所以每次 mmap() 都会发生缺页异常。在内存工作繁忙时，频繁的内存分配会导致大量的缺页异常，使内核的管理负担增大。这也是 malloc() 只对大块内存使用 mmap() 的原因。

brk()系统调用为sys_brk()函数，其参数brk是新的堆顶位置，而mm->brk是原堆顶位置。该函数主要逻辑如下

在 do_brk_flags() 中，调用 find_vma_links() 找到将来的 vm_area_struct 节点在红黑树的位置，找到它的父节点、前序节点。接下来调用 vma_merge()，看这个新节点是否能够和现有树中的节点合并。如果地址是连着的，能够合并，则不用创建新的 vm_area_struct 了，直接跳到 out，更新统计值即可；如果不能合并，则创建新的 vm_area_struct，添加到anon_vma_chain 链表中，也加到红黑树中。

大块内存的申请通过mmap系统调用实现，mmap既可以实现虚拟内存向物理内存的映射，也可以映射文件到自己的虚拟内存空间。映射文件时，实际是映射虚拟内存到物理内存再到文件。

这里主要调用ksys_mmap_pgoff()函数，这里逻辑如下:

vm_mmap_pgoff()函数调用do_mmap_pgoff()，实际调用do_mmap()函数。这里get_unmapped_area()函数负责寻找可映射的区域，mmap_region()负责映射该区域。

更多Linux内核视频教程文本资料免费领取后台私信【 内核大礼包 】自行获取。

首先来看看寻找映射区的函数get_unmapped_area()。

mmap_region()首先会再次检测地址空间是否满足要求，然后清除旧的映射，校验内存的可用性，在一切均满足的情况下调用vma_link()将新创建的vm_area_struct结构挂在mm_struct内的红黑树上。

vma_link()本身是__vma_link()和__vma_link_file()的包裹函数

其中__vma_link()主要是链表和红黑表的插入，这属于基本数据结构 *** 作，不展开讲解。

而__vma_link_file()会对文件映射进行处理，在file结构体中成员f_mapping指向address_space结构体，该结构体中存储红黑树i_mmap挂载vm_area_struct。

至此，我们完成了用户态内存的映射，但是此处仅在虚拟内存中建立了新的区域，尚未真正访问物理内存。物理内存的访问只有在调度到该进程时才会真正分配，即发生缺页异常时分配。

三. 用户态缺页异常   一旦开始访问虚拟内存的某个地址，如果我们发现，并没有对应的物理页，那就触发缺页中断，调用 do_page_fault()。这里的逻辑如下

find_vma()为红黑树查找 *** 作，在此不做展开描述，下面重点看看handle_mm_fault()。这里经过一系列校验之后会根据是否是大页而选择调用hugetlb_fault()或者__handle_mm_fault()

__handle_mm_fault()完成实际上的映射 *** 作。这里涉及到了由pgd, p4g, pud, pmd, pte组成的五级页表，页表索引填充完后调用handle_pte_fault()创建页表项。

handle_pte_fault()处理以下三种情况:

对于匿名页映射，流程如下:

映射文件do_fault()函数调用了fault函数，该函数实际会根据不同的文件系统调用不同的函数，如ext4文件系统中vm_ops指向ext4_file_vm_ops，实际调用ext4_filemap_fault()函数，该函数会调用filemap_fault()完成实际的文件映射 *** 作。

file_map_fault()主要逻辑为:

前文提到了我们会通过主动回收或者被动回收的方式将物理内存已映射的页面回收至硬盘中，当数据再次访问时，我们又需要通过do_swap_page()将其从硬盘中读回来。do_swap_page() 函数逻辑流程如下：查找 swap 文件有没有缓存页。如果没有，就调用 swapin_readahead()将 swap 文件读到内存中来形成内存页，并通过 mk_pte() 生成页表项。set_pte_at 将页表项插入页表，swap_free 将 swap 文件清理。因为重新加载回内存了，不再需要 swap 文件了。

通过以上步骤，用户态的缺页异常就处理完毕了。物理内存中有了页面，页表也建立好了映射。接下来，用户程序在虚拟内存空间里面可以通过虚拟地址顺利经过页表映射的访问物理页面上的数据了。页表一般都很大，只能存放在内存中。 *** 作系统每次访问内存都要折腾两步，先通过查询页表得到物理地址，然后访问该物理地址读取指令、数据。为了加快映射速度，我们引入了 TLB（Translation Lookaside Buffer），我们经常称为快表，专门用来做地址映射的硬件设备。它不在内存中，可存储的数据比较少，但是比内存要快。所以我们可以想象，TLB 就是页表的 Cache，其中存储了当前最可能被访问到的页表项，其内容是部分页表项的一个副本。有了 TLB 之后，我们先查块表，块表中有映射关系，然后直接转换为物理地址。如果在 TLB 查不到映射关系时，才会到内存中查询页表。

和用户态使用malloc()类似，内核态也有相应的内存映射函数：vmalloc()可用于分配不连续物理页（使用伙伴系统），kmem_cache_alloc()和kmem_cache_create()使用slub分配器分配小块内存，而kmalloc()类似于malloc()，在分配大内存的时候会使用伙伴系统，分配小内存则使用slub分配器。分配内存后会转换为虚拟地址，保存在内核页表中进行映射，有需要时直接访问。由于vmalloc()会带来虚拟连续页和物理不连续页的映射，因此一般速度较慢，使用较少，相比而言kmalloc()使用的更为频繁。而kmem_cache_alloc()和kmem_cache_create()会分配更为精准的小内存块用于特定任务，因此也比较常用。

相对于用户态，内核态还有一种特殊的映射：临时映射。内核态高端内存地区为了节省空间会选择临时映射，采用kmap_atomic()实现。如果是 32 位有高端地址的，就需要调用 set_pte 通过内核页表进行临时映射；如果是 64 位没有高端地址的，就调用 page_address，里面会调用 lowmem_page_address。其实低端内存的映射，会直接使用 __va 进行临时映射。

kmap_atomic ()发现没有页表的时候会直接创建页表进行映射。而 vmalloc ()只分配了内核的虚拟地址。所以访问它的时候，会产生缺页异常。内核态的缺页异常还是会调用 do_page_fault()，最终进入vmalloc_fault()。在这里会实现内核页表项的关联 *** 作，从而完成分配，整体流程和用户态相似。

至此，我们分析了内存物理地址和虚拟地址的映射关系，结合前文页的分配和管理，内存部分的主要功能就算是大致分析清楚了，最后引用极客时间中的一幅图作为总结，算是全部知识点的汇总。

1、brk

2、mmap

3、page_fault

linux下的cpu有两个状态：内核态和用户态，内核态的cpu的权限高于用户态下的cpu。linux下的内存分为用户态内存和内核态内存，一般4个G内存，3个G的分给用户态，1个G分给内核态。

linux进程有时需要调用内核资源时，如读写文件，io读写等，这时候是通过系统调用实现对内核资源的访问的，在访问内核资源前是用户栈，经过系统调用进入到内核态时，cpu的状态也由用户态变为内核态，访问的内存就是内核态下管理的内存了-内核栈，对内核里的资源访问完返回，内存又回到了用户栈，cpu也回到用户态。

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位处理器的硬件分页系统都使用了额外的分页级别. 使用的级别取决于处理器的类型

平台名称

页大小

寻址所使用的位数

分页级别数

线性地址分级

alpha8KB43310 + 10 + 10 + 13

ia644KB3939 + 9 + 9 + 12

ppc644KB41310 + 10 + 9 + 12

sh644KB41310 + 10 + 9 + 12

x86_644KB4849 + 9 + 9 + 9 + 12

---