mmap的原理

by 夏泽民 Jan 8, 2020

很多文章分析了mmap的实现原理。从代码的逻辑来分析，总是觉没有把mmap后读写映射区域和普通的read/write联系起来。不得不产生疑问：

1，普通的read/write和mmap后的映射区域的读写到底有什么区别。

2，为什么有时候会选择mmap而放弃普通的read/write。

3，如果文章中的内容有不对是或者是不妥的地方，欢迎大家指正。

围绕着这两个问题分析一下，其实在考虑这些问题的同时不免和其他的很多系统机制产生交互。虽然是讲解mmap，但是很多知识还是为了阐明问题做必要的铺垫。这些知识也正是linux的繁琐所在。一个应用往往和系统中的多种机制交互。这篇文章中尽量减少对源代码的引用和分析。把这样的工作留到以后的细节分析中。但是很多分析的理论依据还是来自于源代码。可见源代码的重要地位。

基础知识：

1，进程每次切换后，都会在tlb base寄存器中重新load属于每一个进程自己的地址转换基地址。在cpu当前运行的进程中都会有current宏来表示当前的进程的信息。应为这个代码实现涉及到硬件架构的问题，为了避免差异的存在在文章中用到硬件知识的时候还是指明是x86的架构，毕竟x86的资料和分析的研究人员也比较多。其实arm还有其他类似的RISC的芯片，只要有mmu支持的，都会有类似的基地址寄存器。

2，在系统运行进程之前都会为每一个进程分配属于它自己的运行空间。并且这个空间的有效性依赖于tlb base中的内容。32位的系统中访问的空间大小为4G。在这个空间中进程是“自由”的。所谓“自由”不是说对于4G的任何一个地址或者一段空间都可以访问。如果要访问，还是要遵循地址有效性，就是tlb base中所指向的任何页表转换后的物理地址。其中的有效性有越界，权限等等检查。

3，任何一个用户进程的运行在系统分配的空间中。这个空间可以有

vma：struct vm_area_struct来表示。所有的运行空间可以有这个结构体描述。用户进程可以分为text data 段。这些段的具体在4G中的位置有不同的vma来描述。Vma的管理又有其他机制保证，这些机制涉及到了算法和物理内存管理等。

系统调用中的write和read：

这里没有指定确切的文件系统类型作为分析的对象。找到系统调用号，然后确定具体的文件系统所带的file operation。在特定的file operation中有属于每一种文件系统自己的操作函数集合。其中就有read和write。

图三：

在真正的把用户数据读写到磁盘或者是存储设备前，内核还会在page cache中管理这些数据。这些page的存在有效的管理了用户数据和读写的效率。用户数据不是直接来自于应用层，读(read)或者是写入(write)磁盘和存储介质，而是被一层一层的应用所划分，在每一层次中都会有不同的功能对应。最后发生交互时，在最恰当的时机触发磁盘的操作。通过IO驱动写入磁盘和存储介质。这里主要强调page cache的管理。应为page的管理设计到了缓存，这些缓存以page的单位管理。在没有IO操作之前，暂时存放在系统空间中，而并未直接写入磁盘或者存贮介质。

系统调用中的mmap：

当创建一个或者切换一个进程的同时，会把属于这个当前进程的系统信息载入。这些系统信息中包含了当前进程的运行空间。当用户程序调用mmap后。函数会在当前进程的空间中找到适合的vma来描述自己将要映射的区域。这个区域的作用就是将mmap函数中文件描述符所指向的具体文件中内容映射过来。

原理是：mmap的执行，仅仅是在内核中建立了文件与虚拟内存空间的对应关系。用户访问这些虚拟内存空间时，页面表里面是没有这些空间的表项的。当用户程序试图访问这些映射的空间时，于是产生缺页异常。内核捕捉这些异常，逐渐将文件载入。所谓的载入过程，具体的操作就是read和write在管理pagecache。Vma的结构体中有很文件操作集。vma操作集中会有自己关于page cache的操作集合。这样，虽然是两种不同的系统调用，由于操作和调用触发的路径不同。但是最后还是落实到了page cache的管理。实现了文件内容的操作。

Ps：

文件的page cache管理也是很好的内容。涉及到了address space的操作。其中很多的内容和文件操作相关。

效率对比：

这里应用了网上一篇文章。发现较好的分析，着这里引用一下。

Mmap：

#include

#include <sys/types.h>

#include <sys/stat.h>

#include

#include <sys/mman.h>

void main()

{

int fd = open(“test.file”, 0);

struct stat statbuf;

char *start;

char buf[2] = {0};

int ret = 0;

fstat(fd, &statbuf);

start = mmap(NULL, statbuf.st_size, PROT_READ, MAP_PRIVATE, fd, 0);

do {

*buf = start[ret++];

}while(ret < statbuf.st_size);

}

Read：

#include

void main()

{

FILE *pf = fopen(“test.file”, ”r”);

char buf[2] = {0};

int ret = 0;

do {

ret = fread(buf, 1, 1, pf);

}while(ret);

}

运行结果：

[xiangy@compiling-server test_read]$ time ./fread

real 0m0.901s

user 0m0.892s

sys 0m0.010s

[xiangy@compiling-server test_read]$ time ./mmap

real 0m0.112s

user 0m0.106s

sys 0m0.006s

[xiangy@compiling-server test_read]$ time ./read

real 0m15.549s

user 0m3.933s

sys 0m11.566s

[xiangy@compiling-server test_read]$ ll test.file

-rw-r–r– 1 xiangy svx8004 23955531 Sep 24 17:17 test.file

可以看出使用mmap后发现，系统调用所消耗的时间远远比普通的read少很多。

对于mmap，您是否能从原理上解析以下三个问题：

mmap比物理内存+swap空间大情况下，是否有问题？
MAP_SHARED，MAP_PRIVATE，MAP_ANONYMOUS，MAP_NORESERVE到底有什么区别?
常听说mmap的读写比传统的系统调用(read, write)快，但真的是这样子吗？原因是什么？
要解决这些疑问，可能还需要在操作系统层面多了解。本文将尝试通过这些问题深入剖析，希望通过这篇文章，能使大家对mmap有较深入的认识，也能在存储引擎的设计中，有所参考。

背景
最近在研发分布式日志存储系统，这是一个基于Raft协议的自研分布式日志存储系统，Logstore则是底层存储引擎。

Logstore中，使用mmap对数据文件进行读写。Logstore的存储结构简化如下图：

logstore mmap.png
Logstore使用了Segments Files + Index Files的方式存储Log，Segment File是存储主体，用于存储Log数据，使用定长的方式，默认每个512M，Index File主要用于Segment File的内容检索。

Logstore使用mmap的方式读写Segment File，Segments Files的个数，主要取决于磁盘空间或者业务需求，一般情况下，Logstore会存储1T~5T的数据。

什么是mmap
我们先看看什么是mmap。

在«深入理解计算机系统»这本书中，mmap定义为：Linux通过将一个虚拟内存区域与一个磁盘上的对象(object)关联起来，以初始化这个虚拟内存区域的内容，这个过程称为内存映射(memory mapping)。

在Logstore中，mapping的对象是普通文件(Segment File)。

mmap的原理
mmap在进程虚拟内存做了什么
我们先来简单看一下mapping一个文件，mmap做了什么事情。如下图所示：

map file.png
假设我们mmap的文件是FileA，在调用mmap之后，会在进程的虚拟内存分配地址空间，创建映射关系。

这里值得注意的是，mmap只是在虚拟内存分配了地址空间，举个例子，假设上述的FileA是2G大小

[dragon@xxx.xxx] ls -lat FileA

2147483648 Apr 25 10:22 FileA
在mmap之后，查看mmap所在进程的maps描述，可以看到

[dragon@xxx.xxx] cat maps
….
7f35eea8d000-7f366ea8d000 rw-s 00000000 08:03 13110516 FileA
….
由上可以看到，在mmap之后，进程的地址空间7f35eea8d000-7f366ea8d000被分配，并且map到FileA，7f366ea8d000减去7f35eea8d000，刚好是2147483648(ps: 这里是整个文件做mapping)

mmap在物理内存做了什么
在Linux中，VM系统通过将虚拟内存分割为称作虚拟页(Virtual Page，VP)大小固定的块来处理磁盘(较低层)与上层数据的传输，一般情况下，每个页的大小默认是4096字节。同样的，物理内存也被分割为物理页(Physical Page，PP)，也为4096字节。

上述例子，在mmap之后，如下图：

virtual-physical.png
在mmap之后，并没有在将文件内容加载到物理页上，只上在虚拟内存中分配了地址空间。当进程在访问这段地址时（通过mmap在写入或读取时FileA），若虚拟内存对应的page没有在物理内存中缓存，则产生”缺页”，由内核的缺页异常处理程序处理，将文件对应内容，以页为单位(4096)加载到物理内存，注意是只加载缺页，但也会受操作系统一些调度策略影响，加载的比所需的多，这里就不展开了。
(PS: 再具体一些，进程在访问7f35eea8d000这个进程虚拟地址时，MMU通过查找页表，发现对应内容未缓存在物理内存中，则产生”缺页”)

缺页处理后，如下图：

virtual-physical assign.png
mmap的分类
我认为从原理上，mmap有两种类型，一种是有backend，一种是没有backend。

有backend
backend mmap.png
这种模式将普通文件做memory mapping(非MAP_ANONYMOUS)，所以在mmap系统调用时，需要传入文件的fd。这种模式常见的有两个常用的方式，MAP_SHARED与MAP_PRIVATE，但它们的行为却不相同。

1) MAP_SHARED

这个方式我认为可以从两个角度去看：

进程间可见：这个被提及太多，就不展开讨论了
写入/更新数据会回写backend，也就是回写文件：这个是很关键的特性，是在Logstore设计实现时，需要考虑的重点。Logstore的一个基本功能就是不断地写入数据，从实现上看就是不断地mmap文件，往内存写入/更新数据以达到写入文件的目的。但物理内存是有限的，在写入数据超过物理内存时，操作系统会进行页置换，根据淘汰算法，将需要淘汰的页置换成所需的新页，而恰恰因为是有backend的，所以mmap对应的内存是可以被淘汰的（若内存页是”脏”的，则操作系统会先将数据回写磁盘再淘汰）。这样，就算mmap的数据远大于物理内存，操作系统也能很好地处理，不会产生功能上的问题。
2) MAP_PRIVATE

这是一个copy-on-write的映射方式。虽然他也是有backend的，但在写入数据时，他会在物理内存copy一份数据出来(以页为单位)，而且这些数据是不会被回写到文件的。这里就要注意，因为更新的数据是一个副本，而且不会被回写，这就意味着如果程序运行时不主动释放，若更新的数据超过可用物理内存+swap space，就会遇到OOM Killer。

无backend
无backend通常是MAP_ANONYMOUS，就是将一个区域映射到一个匿名文件，匿名文件是由内核创建的。因为没有backend，写入/更新的数据之后，若不主动释放，这些占用的物理内存是不能被释放的，同样会出现OOM Killer。

mmap比内存+swap空间大情况下，是否有问题
到这里，这个问题就比较好解析了。我们可以将此问题分离为：

虚拟内存是否会出问题
物理内存是否会出问题
– 虚拟内存是否会出问题：

回到上述的”mmap在进程虚拟内存做了什么”，我们知道mmap会在进程的虚拟内存中分配地址空间，比如1G的文件，则分配1G的连续地址空间。那究竟可以maping多少呢？在64位操作系统，寻址范围是2^64 ，除去一些内核、进程数据等地址段之外，基本上可以认为可以mapping无限大的数据(不太严谨的说法)。

– 物理内存是否会出问题
回到上述”mmap的分类”，对于有backend的mmap，而且是能回写到文件的，映射比内存+swap空间大是没有问题的。但无法回写到文件的，需要非常注意，主动释放。

MAP_NORESERVE
MAP_NORESERVE是mmap的一个参数，MAN的说明是”Do not reserve swap space for this mapping. When swap space is reserved, one has the guarantee that it is possible to modify the mapping.”。

我们做个测试：

场景A：物理内存+swap space: 16G，映射文件30G，使用一个进程进行mmap，成功后映射后持续写入数据
场景B：物理内存+swap space: 16G，映射文件15G，使用两个进程进行mmap，成功后映射后持续写入数据

场景序列映射类型结果
A 1 MAP_PRIVATE mmap报错
A 2 MAP_PRIVATE + MAP_NORESERVE mmap成功，在持续写入情况下，遇到OOM Killer
A 3 MAP_SHARED mmap成功，在持续写入正常
B 4 MAP_PRIVATE mmap成功，在持续写入情况下，有一个进程会遇到OOM Killer
B 5 MAP_PRIVATE + MAP_NORESERVE mmap成功，在持续写入情况下，有一个进程会遇到OOM Killer
B 6 MAP_SHARED mmap成功，在持续写入正常
从上述测试可以看出，从现象上看，NORESERVE是绕过mmap的校验，让其可以mmap成功。但其实在RESERVE的情况下(序列4)，从测试结果看，也没有保障。

mmap的性能
mmap的性能经常与系统调用（write/read）做对比。

我们将读写分开看，先尝试从原理上分析两者的差异，然后再通过测试验证。

mmap的写性能
我们先来简单讲讲write系统调用写文件的过程：

write process.png
Step1：进程(用户态)调用write系统调用，并告诉内核需要写入数据的开始地址与长度（告诉内核写入的数据在哪）。
Step2：内核write方法，将校验用户态的数据，然后复制到kernel buffer（这里是Page Cache）。
[ ps: 特意查了ext4 write的内核实现，write是直接将user buffer copy到page中 ]
Step3: 由操作系统调用，将脏页回写到磁盘（通常这是异步的）
再来简单讲讲使用mmap时，写入文件流程：

Step1：进程(用户态)将需要写入的数据直接copy到对应的mmap地址(内存copy)
Step2：
2.1) 若mmap地址未对应物理内存，则产生缺页异常，由内核处理
2.2) 若已对应，则直接copy到对应的物理内存
Step3：由操作系统调用，将脏页回写到磁盘（通常这是异步的）
系统调用会对性能有影响，那么从理论上分析:

若每次写入的数据大小接近page size(4096)，那么write调用与mmap的写性能应该比较接近（因为系统调用次数相近）
若每次写入的数据非常小，那么write调用的性能应该远慢于mmap的性能。
下面我们对两者进行性能测试：

场景：对2G的文件进行顺序写入(go语言编写)

mmap 耗时	write 耗时
1 byte	22.14s	>300s
100 bytes	2.84s	22.86s
512 bytes	2.51s	5.43s
1024 bytes	2.48s	3.48s
2048 bytes	2.47s	2.34s
4096 bytes	2.48s	1.74s
8192 bytes	2.45s	1.67s
10240 bytes	2.49s	1.65s

可以看到mmap在100byte写入时已经基本达到最大写入性能，而write调用需要在4096(也就是一个page size)时，才能达到最大写入性能。

从测试结果可以看出，在写小数据时，mmap会比write调用快，但在写大数据时，反而没那么快(但不太确认是否go的slice copy的性能问题，没时间去测C了)。

测试结果与理论推导吻合。

mmap的读性能
我们还是来简单分析read调用与mmap的流程：

read process.png
从图中可以看出，read调用确实比mmap多一次copy。因为read调用，进程是无法直接访问kernel space的，所以在read系统调用返回前，内核需要将数据从内核复制到进程指定的buffer。但mmap之后，进程可以直接访问mmap的数据(page cache)。

从原理上看，read性能会比mmap慢。

接下来实测一下性能区别：

场景：对2G的文件进行顺序读取(go语言编写)
(ps: 为了避免磁盘对测试的影响，我让2G文件都缓存在pagecache中)

mmap 耗时	write 耗时
1 byte	8215.4ms	> 300s
100 bytes	86.4ms	8100.9ms
512 bytes	16.14ms	1851.45ms
1024 bytes	8.11ms	992.71ms
2048 bytes	4.09ms	636.85ms
4096 bytes	2.07ms	558.10ms
8192 bytes	1.06ms	444.83ms
10240 bytes	867.88µs	475.28ms

由上可以看出，在read上面，mmap比write的性能差别还是很大的。测试结果与理论推导吻合。

结束语
对mmap的深入了解，能帮助我们在设计存储系统时，更好地进行决策。
比如，假设需要设计一个底层的数据结构是B+ Tree，node操作以Page单位的单机存储引擎，根据上述推论，写入使用系统调用，而读取使用mmap，可以达到最优的性能。而LMDB就是如此实现的。

很多文章分析了mmap的实现原理。从代码的逻辑来分析，总是觉没有把mmap后读写映射区域和普通的read/write联系起来。不得不产生疑问：

1，普通的read/write和mmap后的映射区域的读写到底有什么区别。

2，为什么有时候会选择mmap而放弃普通的read/write。

3，如果文章中的内容有不对是或者是不妥的地方，欢迎大家指正。

基础知识：

3，任何一个用户进程的运行在系统分配的空间中。这个空间可以有

vma：struct vm_area_struct来表示。所有的运行空间可以有这个结构体描述。用户进程可以分为text data 段。这些段的具体在4G中的位置有不同的vma来描述。Vma的管理又有其他机制保证，这些机制涉及到了算法和物理内存管理等。请看一下两个图片：

图一：

图二：

系统调用中的write和read：

图三：

系统调用中的mmap：

Ps：

文件的page cache管理也是很好的内容。涉及到了address space的操作。其中很多的内容和文件操作相关。

效率对比：

这里应用了网上一篇文章。发现较好的分析，着这里引用一下。

Mmap：

#include

#include <sys/types.h>

#include <sys/stat.h>

#include

#include <sys/mman.h>

void main()

{

int fd = open(“test.file”, 0);

struct stat statbuf;

char *start;

char buf[2] = {0};

int ret = 0;

fstat(fd, &statbuf);

start = mmap(NULL, statbuf.st_size, PROT_READ, MAP_PRIVATE, fd, 0);

do {

*buf = start[ret++];

}while(ret < statbuf.st_size);

}

Read：

#include

void main()

{

FILE *pf = fopen(“test.file”, “r”);

char buf[2] = {0};

int ret = 0;

do {

ret = fread(buf, 1, 1, pf);

}while(ret);

}

运行结果：

[xiangy@compiling-server test_read]$ time ./fread

real 0m0.901s

user 0m0.892s

sys 0m0.010s

[xiangy@compiling-server test_read]$ time ./mmap

real 0m0.112s

user 0m0.106s

sys 0m0.006s

[xiangy@compiling-server test_read]$ time ./read

real 0m15.549s

user 0m3.933s

sys 0m11.566s

[xiangy@compiling-server test_read]$ ll test.file

-rw-r–r– 1 xiangy svx8004 23955531 Sep 24 17:17 test.file

可以看出使用mmap后发现，系统调用所消耗的时间远远比普通的read少很多。

首先，文件映射是虚存的中心概念, 文件映射一方面给用户提供了一组措施, 好似用户将文件映射到自己地址空间的某个部分, 使用简单的内存访问指令读写文件；另一方面, 它也可以用于内核的基本组织模式, 在这种模式种, 内核将整个地址空间视为诸如文件之类的一组不同对象的映射. 中的传统文件访问方式是, 首先用open系统调用打开文件, 然后使用read, write以及lseek等调用进行顺序或者随即的I/O. 这种方式是非常低效的, 每一次I/O操作都需要一次系统调用. 另外, 如果若干个进程访问同一个文件, 每个进程都要在自己的地址空间维护一个副本, 浪费了内存空间. 而如果能够通过一定的机制将页面映射到进程的地址空间中, 也就是说首先通过简单的产生某些内存管理数据结构完成映射的创建. 当进程访问页面时产生一个缺页中断, 内核将页面读入内存并且更新页表指向该页面. 而且这种方式非常方便于同一副本的共享.

接下来，我们来看下在linux内核中mmap的函数原型：

void *mmap(void *addr,size_t length ,int prot, int flags, int fd, off_t offset)；

其中，addr：是映射区起始地址，通常设为NULL，由系统指定。

length：将文件的多大长度映射到内存

prot：映射区的保护方式，可以是：

PROT_EXEC：映射区可被执行； PROT_READ：映射区可被读取；

PROT_WRITE：映射区可被写入； PROT_NONE：映射区不能存取。

flag：映射区的特性，可以是：

MAP_SHARD：对映射区的写入数据会复制回文件，且允许其他映射该文件的进程共享

MAP_PRIVATE：对映射区域的写入数据会产生一个映射的复制（copy-on-write），对此区域所做的修改不会写回到原文件

其他标识这里就不再写出来了，可以通过man mmap查看

fd：由open返回的文件描述符，代笔要映射的文件；

offset：以文件开始处的偏移量，必须是分页大小的整数倍，通常为0,表示从文件头开始映射。

下面主要是分析有关mmap系统调用的实现过程:

1.先通过文件系统定位要映射的文件；
2.权限检查, 映射的权限不会超过文件打开的方式, 也就是说如果文件是以只读方式打开, 那么则不允许建立一个可写映射；

3.创建一个vma对象, 并对之进行初始化；
4.调用映射文件的mmap函数, 其主要工作是给vm_ops向量表赋值；
5.把该vma链入该进程的vma链表中, 如果可以和前后的vma合并则合并；
6.如果是要求VM_LOCKED(映射区不被换出)方式映射, 则发出缺页请求, 把映射页面读入内存中.

下面此图来次《Unix Network programming》卷二12.2节，对mmap有个比较深刻的印象

附加：mmap的应用源代码示例（把文件映射到内存）

#include <sys/mman.h>

#include <sys/types.h>
#include <sys/stat.h>

#include
#include
#include

int main(int argc, char **argv)
{
int fd;
char *mapped_mem, * p;
int flength = 1024;
void * start_addr = 0;

   fd = open(argv[1], O_RDWR | O_CREAT, S_IRUSR | S_IWUSR);

   flength = lseek(fd, 1, SEEK_END);

   write(fd, "\0", 1);   

   lseek(fd, 0, SEEK_SET);

   mapped_mem = mmap(start_addr, flength, PROT_READ, MAP_PRIVATE, fd, 0); //允许读，不允许其它进程访问此内存区域

   printf("%s\n", mapped_mem);

   close(fd);

   munmap(mapped_mem, flength);

   return 0; }

编译运行此程序：

gcc -o map mmap.c

./map file_name

有待补充……

https://zhuanlan.zhihu.com/p/69555454
https://www.zhihu.com/question/48161206

Category linux