Linux进程间通信--mmap()共享内存（二）

浏览数：102 / 时间：2015年06月20日

内核怎样保证各个进程寻址到同一个共享内存区域的内存页面

1、page cache及swap cache中页面的区分：一个被访问文件的物理页面都驻留在page cache或swap cache中，一个页面的所有信息由struct page来描述。struct page中有一个域为指针mapping ，它指向一个struct address_space类型结构。page cache或swap cache中的所有页面就是根据address_space结构以及一个偏移量来区分的。

2、文件与address_space结构的对应：一个具体的文件在打开后，内核会在内存中为之建立一个struct inode结构，其中的i_mapping域指向一个address_space结构。这样，一个文件就对应一个address_space结构，一个address_space与一个偏移量能够确定一个page cache 或swap cache中的一个页面。因此，当要寻址某个数据时，很容易根据给定的文件及数据在文件内的偏移量而找到相应的页面。

3、进程调用mmap()时，只是在进程空间内新增了一块相应大小的缓冲区，并设置了相应的访问标识，但并没有建立进程空间到物理页面的映射。因此，第一次访问该空间时，会引发一个缺页异常。

4、对于共享内存映射情况，缺页异常处理程序首先在swap cache中寻找目标页（符合address_space以及偏移量的物理页），如果找到，则直接返回地址；如果没有找到，则判断该页是否在交换区(swap area)，如果在，则执行一个换入操作；如果上述两种情况都不满足，处理程序将分配新的物理页面，并把它插入到page cache中。进程最终将更新进程页表。
注：对于映射普通文件情况（非共享映射），缺页异常处理程序首先会在page cache中根据address_space以及数据偏移量寻找相应的页面。如果没有找到，则说明文件数据还没有读入内存，处理程序会从磁盘读入相应的页面，并返回相应地址，同时，进程页表也会更新。

5、所有进程在映射同一个共享内存区域时，情况都一样，在建立线性地址与物理地址之间的映射之后，不论进程各自的返回地址如何，实际访问的必然是同一个共享内存区域对应的物理页面。
注：一个共享内存区域可以看作是特殊文件系统shm中的一个文件，shm的安装点在交换区上。

mmap()系统调用使得进程之间通过映射同一个普通文件实现共享内存。普通文件被映射到进程地址空间后，进程可以向访问普通内存一样对文件进行访问，不必再调用read()，write（）等操作。

注：实际上，mmap()系统调用并不是完全为了用于共享内存而设计的。它本身提供了不同于一般对普通文件的访问方式，进程可以像读写内存一样对普通文件的操作。而Posix或系统V的共享内存IPC则纯粹用于共享目的，当然mmap()实现共享内存也是其主要应用之一。

系统调用mmap()用于共享内存的两种方式：

（1）使用普通文件提供的内存映射：适用于任何进程之间；此时，需要打开或创建一个文件，然后再调用mmap()；典型调用代码如下：

	fd=open(name, flag, mode);
if(fd<0)
	...

ptr=mmap(NULL, len , PROT_READ|PROT_WRITE, MAP_SHARED , fd , 0);通过mmap()实现共享内存的通信方式有许多特点和要注意的地方，我们将在范例中进行具体说明。

（2）使用特殊文件提供匿名内存映射：适用于具有亲缘关系的进程之间；由于父子进程特殊的亲缘关系，在父进程中先调用mmap()，然后调用fork()。那么在调用fork()之后，子进程继承父进程匿名映射后的地址空间，同样也继承mmap()返回的地址，这样，父子进程就可以通过映射区域进行通信了。注意，这里不是一般的继承关系。一般来说，子进程单独维护从父进程继承下来的一些变量。而mmap()返回的地址，却由父子进程共同维护。
对于具有亲缘关系的进程实现共享内存最好的方式应该是采用匿名内存映射的方式。此时，不必指定具体的文件，只要设置相应的标志即可

说起共享内存，一般来说会让人想起下面一些方法：
1、多线程。线程之间的内存都是共享的。更确切的说，属于同一进程的线程使用的是同一个地址空间，而不是在不同地址空间之间进行内存共享；
2、父子进程间的内存共享。父进程以MAP_SHARED|MAP_ANONYMOUS选项mmap一块匿名内存，fork之后，其子孙进程之间就能共享这块内存。这种共享内存由于受到进程父子关系的限制，一般较少使用；
3、mmap文件。多个进程mmap到同一个文件，实际上就是大家在共享文件page cache中的内存。不过文件牵涉到磁盘的读写，用来做共享内存显然十分笨重，所以就有了不跟磁盘扯上关系的内存文件，也就是我们这里要讨论的tmpfs和shmem；

tmpfs是一套虚拟的文件系统，在其中创建的文件都是基于内存的，机器重启即消失。
shmem是一套ipc，通过相应的ipc系统调用shmget能够以指定key创建一块的共享内存。需要使用这块内存的进程可以通过shmat系统调用来获得它。
虽然是两套不同的接口，但是在内核里面的实现却是同一套。shmem内部挂载了一个tmpfs分区（用户不可见），shmget就是在该分区下获取名为"SYSV${key}"的文件。然后shmat就相当于mmap这个文件。
所以我们接下来就把tmpfs和shmem当作同一个东西来讨论了。

tmpfs/shmem是一个介于文件和匿名内存之间的东西。
一方面，它具有文件的属性，能够像操作文件一样去操作它。它有自己inode、有自己的page cache；
另一方面，它也有匿名内存的属性。由于没有像磁盘这样的外部存储介质，内核在内存紧缺时不能简单的将page从它们的page cache中丢弃，而需要swap-out；（参阅《linux页面回收浅析》）

对tmpfs/shmem内存的读写，就是对page cache中相应位置的page所代表的内存进行读写，这一点跟普通的文件映射没有什么不同。
如果进程地址空间的相应位置尚未映射，则会建立到page cache中相应page的映射；
如果page cache中的相应位置还没有分配page，则会分配一个。当然，由于不存在磁盘上的源数据，新分配的page总是空的（特别的，通过read系统调用去读一个尚未分配page的位置时，并不会分配新的page，而是共享ZERO_PAGE）；
如果page cache中相应位置的page被回收了，则会先将其恢复；

对于第三个“如果”，tmpfs/shmem和普通文件的page回收及其恢复方式是不同的：
page回收时，跟普通文件的情况一样，内核会通过prio_tree反向映射找到映射这个page的每一个page table，然后将其中对应的pte清空。
不同之处是普通文件的page在确保与磁盘同步（如果page为脏的话需要刷回磁盘）之后就可以丢弃了，而对于tmpfs/shmem的page则需要进行swap-out。
注意，匿名page在被swap-out时，并不是将映射它的pte清空，而是得在pte上填写相应的swap_entry，以便知道page被换出到哪里去，否则再需要这个page的时候就没法swap-in了。
而tmpfs/shmem的page呢？page table中对应的pte被清空，swap_entry会被存放在page cache的radix_tree的对应slot上。

等下一次访问触发page fault时，page需要恢复。
普通文件的page恢复跟page未分配时的情形一样，需要新分配page、然后根据映射的位置重新从磁盘读出相应的数据；
而tmpfs/shmem则是通过映射的位置找到radix_tree上对应的slot，从中得到swap_entry，从而进行swap-in，并将新的page放回page cache；

这里就有个问题了，在page cache的radix_tree的某个slot上，怎么知道里面存放着的是正常的page？还是swap-out后留下的swap_entry？
如果是swap_entry，那么slot上的值将被加上RADIX_TREE_EXCEPTIONAL_ENTRY标记（值为2）。swap_entry的值被左移两位后OR上RADIX_TREE_EXCEPTIONAL_ENTRY，填入slot。
也就是说，如果${slot} & RADIX_TREE_EXCEPTIONAL_ENTRY != 0，则它代表swap_entry，且swap_entry的值是${slot} >> 2；否则它代表page，${slot}就是指向page的指针，当然其值可能是NULL，说明page尚未分配。
那么显然，page的地址值其末两位肯定是0，否则就可能跟RADIX_TREE_EXCEPTIONAL_ENTRY标记冲突了；而swap_entry的值最大只能是30bit或62bit（对应32位或64位机器），否则左移两位就溢出了。

最后以一张图说明一下匿名page、文件映射page、tmpfs/shmem page的回收及恢复过程：

技术分享