Mmap系列一： Mmap的实现原理和应用（及与read/fread的比较）

转载：Mmap的实现原理和应用

很多文章分析了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的操作。其中很多的内容和文件操作相关。

效率对比：

这里应用了网上一篇文章。发现较好的分析，着这里引用一下。linux下文件读取性能比较（fread、read、mmap）。

在进行大规模数据处理时，读文件很有可能成为速度瓶颈。不管你的CPU有4个核还是8个核，主频有2G还是3G，硬盘IO速度总是有个上限的。在本人最近的一次经历中，对一个11G的文本进行数据处理，一共耗时34.8秒，其中竟然有30.2秒用在访问IO上，占了所有时间的87%左右。
        虽然说硬盘IO是有上限的，那么C++为我们提供的各函数，是否都能让我们达到这个上限呢？为了求得真相，我对这个11G的文本用fread函数读取，在linux下用iostat检查硬盘的访问速度，发现读的速度大约在380M/s。然后用dd指令测了一下读文本的访问速度，发现速度可以达到460M/s。可见单线程fread访问并没有达到硬盘的读取上限。第一次考虑会不会是fread访问硬盘的时候有一些固定开销，用多线程可以达到流水访问IO的效果提高读文本的效率，结果发现多线程也只有380M/s的读取速率。

        为什么fread的效率达不到最大呢？查阅一些资料才知，用fread/fwrite方式访问硬盘，用户须向内核指定要读多少，内核再把得到的内容从内核缓冲池拷向用户空间；写也须要有一个大致如此的过程。这样在访问IO的时候就多经历了这么一个内核的buffer，造成速度的限制。一个解决的办法是mmap。mmap就是通过把文件的某一块内容直接映射到用户空间上，用户可以直接向内核缓冲池读写这一块内容，这样一来就少了内核与用户空间的来回拷贝所以通常更快。

        mmap的使用方法如下：

char *data = NULL;

int fd=open(“file.txt”,O_RDONLY);

long size = lseek(fd, 0, SEEK_END);

data = (char *) mmap( NULL, size ,PROT_READ, MAP_PRIVATE, fd, 0 );

        这时file.txt文件中的数据就可以从data指针指向的首地址开始访问了。

        为了从数据说明这个问题，我引用一位网友的结论，希望对大家有所启发。

方法/平台/时间(秒)	Linux gcc	Windows mingw	Windows VC2008
scanf	2.010	3.704	3.425
cin	6.380	64.003	19.208
cin取消同步	2.050	6.004	19.616
fread	0.290	0.241	0.304
read	0.290	0.398	不支持
mmap	0.250	不支持	不支持

 

另一篇更详细的比较了fread/read/map的性能从"READ"看系统调用的耗时