深入剖析Linux内核反向映射机制

Cheetah，曾为U-boot社区和Linux内核社区提交过若干补丁，主要从事Linux相关系统软件开发工作，负责Soc芯片BringUp及系统软件开发，喜欢阅读内核源代码，在不断的学习和工作中深入理解内存管理，进程调度，文件系统，设备驱动等内核子系统。

为了系统的安全性，Linux内核将各个用户进程运行在各自独立的虚拟地址空间，用户进程之间通过虚拟地址空间相互隔离，不能相互访问，一个进程的奔溃不会影响到整个系统的异常也不会干扰到系统以及其他进程运行。

Linux内核可以通过共享内存的方式为系统节省大量内存，例如fork子进程的时候，父子进程通过只读的方式共享所有的私有页面。再比如通过IPC共享内存方式，各个不相干的进程直接可以共享一块物理内存等等。

本文目录：

1.反向映射的发展

2.反向映射应用场景

3.匿名页的反向映射

4.文件页的反向映射

5.ksm页的反向映射

5.总结

注： 反向映射机制是Linux内核虚拟内存管理的难点也是理解内存管理的关键技术之一 ！！

1.反向映射的发展

接着就在2.6内核的时候，内核大神们想到了复用page结构中的mapping字段，然后通过红黑树的方式来组织所有映射这个页的vma,形成了匿名页和文件页的反向映射机制。

但是后来匿名页的反向映射遇到了效率和锁竞争激烈问题，就促使了目前使用的通过avc的方式联系各层级反向映射结构然后将锁的粒度降低的这种方式。可以看到反向映射的发展是伴随着Linux内核的发展而发展，是一个不断进行优化演进的过程。

2.反向映射应用场景

那么为何在Linux内核中需要反向映射这种机制呢？它究竟为了解决什么样的问题而产生的呢？

试想有如下场景：

（1）一个物理页面被多个进程的vma所映射，系统过程中发生了内存不足，需要回收一些页面，正好发现这个页面是适合我们回收利用的，我们能够直接把这个页面还给伙伴系统吗？答案肯定是不能。因为这个页面被很多个进程所共享，我们必须做的事情就是断开这个页面的所以映射关系，这就是 反向映射所做的事情 。

（2）一些情况我们需要将一个页面迁移到另一个页面，但是牵一发而动全身，可能有一些进程已经映射这个即将要迁移的页面到自己的vma中，那么这个时候同样需要我们知道究竟这个页面被哪些vma所映射呢？这同样是

反向映射所做的事情

。

实际上，反向映射的主要应用场景为内存回收和页面迁移，当系统发生 内存回收和页面迁移 的时候，对于每一个候选页Linux内核都会判断是否为映射页，如果是，就会调用try_to_unmap 来解除页表映射关系，本文也主要来从 try_to_unmap 函数来解读反向映射机制。

如果我们在细致到其他的内核子系统会发现，在 内存回收，内存碎片整理，CMA, 巨型页，页迁移 等各个场景中都能发现反向映射所做的关键性的工作，所有理解反向映射机制在Linux内核中的实现是理解掌握这些子系统的基础和关键性所在，否则你即将不能理解这些技术背后的脊髓所在，所以说理解反向映射这种机制对于理解Linux内核内存管理是至关重要的！！！

3.匿名页的反向映射

而在缺页异常do_anonymous_page的时候将page和vma相关联。

当内存回收或页面迁移的时候，内核路径最终会调用到：

try_to_unmap //mm/rmap.c
->rmap_walk
  ->rmap_walk_anon
     ->anon_vma_interval_tree_foreach(avc, &anon_vma->rb_root,pgoff_start, pgoff_end)
         ->rwc->rmap_one
			->try_to_unmap_one

对于候选页，会拿到候选页相关联的anon_vma，然后从anon_vma的红黑树中遍历到所有共享这个页的vma，然后对于每一个vma通过try_to_unmap_one来处理相对应的页表项， 将映射关系解除 。

4.文件页的反向映射

文件页的共享主要发生在多个进程共享libc库 ，同一个库文件可以只需要读取到page cache一次，然后通过各个进程的页表映射到各个进程的vma中。

当内存回收或页面迁移的时候，内核路径最终会调用到：

try_to_unmap //mm/rmap.c
->rmap_walk
  ->rmap_walk_file
    ->vma_interval_tree_foreach(vma, &mapping>i_mmap,pgoff_start, pgoff_end) 
         ->rwc->rmap_one

对于每一个候选的文件页，如果是映射页，就会遍历page所对应的address_space的区间树，对于每一个满足条件的vma，调用try_to_unmap_one来找到pte并解除映射关系。

5.ksm页的反向映射

ksm机制是内核将页面内容完全相同的页面进行合并（ksm管理的都是匿名页），将映射到这个页面的页表项标记为只读，然后释放掉原来的页表，来达到节省大量内存的目的，这对于host中开多个虚拟机的应用场景非常有用。

ksm机制中会管理两课红黑树，一棵是stable tree,一棵是unstable tree，stable tree中的每个节点 stable_node 中管理的页面都是页面内容完全相同的页面（被叫做kpage）,共享kpage的页面的页表项都会标记为只读，而且对于原来的候选页都会有rmap_item来描述他的反向映射（其中的anon_vma成员的红黑树是描述映射这个候选页的所有vma的集合），合并的时候会加入到对应的stable tree节点和链表中。

当内存回收或页面迁移的时候，内核路径最终会调用到：

try_to_unmap //mm/rmap.c
->rmap_walk
   ->rmap_walk_ksm  //mm/ksm.c
        -> hlist_for_each_entry(rmap_item, &stable_node->hlist, hlist)
 	->anon_vma_interval_tree_foreach(vmac, &anon_vma->rb_root,0, ULONG_MAX) 
	  ->rwc->rmap_one

对于一个ksm页面，反向映射的时候，会拿到ksm页面对应的节点，然后遍历节点的hlist链表，拿到每一个anon_vma，然后就和上面介绍的匿名页的反向映射一样了，从anon_vma的红黑树中找到所有的vma，最后try_to_unmap_one来找到pte并解除映射关系。

6.总结

前面我们介绍了 反向映射的三种类型，匿名页，文件页和ksm页的反向映射,分别通过page所对应的的vma, address_space, stable_node结构来查找vma 。当然我们只是介绍了Linux内核中的反向映射的冰山一角，主要是try_to_unmap函数，其实每种反向映射各个数据结构建立的过程错综复杂，一篇文章三言两语也说不清楚，他们散落在Linux内核源代码的进程创建fork，内存映射mmap,缺页异常处理，文件系统等各个角落。

诚然，如果我们搞不清楚各种反正映射所对应的各种数据结构之间的关系，或者只是有一些概念上的了解，并没有真正掌握这种机制的实现原理，对于我们来理解Linux内核虚拟内存管理来说是一种障碍，不懂得反向映射内存管理 中的很多问题是搞不明白的！

（END）

相关阅读：《深入剖析Linux内核反向映射机制》在线视频

更多精彩，尽在"Linux阅码场"，扫描下方二维码关注