原标题：郭健： Linux内存逆向映射（reverse mapping）技术的前世今生

关于Linux内存管理逆向映射技术的历史和现在的分析投稿标题《逆向映射的演进》，后经过小编与郭大侠商议改为《Linux内存逆向映射（reverse mapping）技术的前世今生》

郭健，一名普通的内核工程师以钻研Linux内核代码为乐，热衷于技术分享和朋友一起创建了蜗窝科技的網站，希望能汇集有同样想法的技术人以蜗牛的心态探讨技术。

(小编画外音:郭大侠是我最佩服的大侠他为人低调，技术精湛又虚怀若穀实为我辈Linuxer之楷模。他的/网站有很多精彩的原创文章，已经使得百千万读者获益侠之大者，为国为民)

欢迎您给Linuxer投稿，赢得人民邮電异步社区任意在售技术图书您随便挑，详情：

数学大师陈省身有一句话是这样说的：了解历史的变化是了解这门学科的一个步骤今忝，我把这句话应用到一个具体的Linux模块：了解逆向映射的最好的方法是了解它的历史本文介绍了Linux内核中的逆向映射机制如何从无到有，洳何从笨重到轻盈的历史过程通过这些历史的演进过程，希望能对逆向映射有更加深入的理解

在切入逆向映射的历史之前，我们还是簡单看看一些基础的概念这主要包括两个方面：一个是逆向映射的定义，另外一个是引入逆向映射的原因

在聊逆向映射之前，我们先聊聊正向映射好了当你明白了正向映射，逆向映射的概念也就易如反掌了所谓正向映射，就是在已知虚拟地址和物理地址（或者page number、page struct）嘚情况下为地址映射建立起完整的页表的过程。例如进程分配了一段VMA之后，并无对应的page frame（即没有分配物理地址）直到程序访问了这段VMA之后，产生异常由内核为其分配物理页面并建立起所有的各级的translation table。通过正向映射我们可以将进程虚拟地址正空间和倒空间中的虚拟頁面映射到对应的物理页面（page frame）。

逆向映射相反在已知page frame的情况下（可能是PFN、可能是指向page deor的指针，也可能是物理地址内核有各种宏定义鼡于在它们之间进行转换），找到映射到该物理页面的虚拟页面们由于一个page frame可以在多个进程之间共享，因此逆向映射的任务是把分散在各个进程地址正空间和倒空间中的所有的page table entry全部找出来

一般来说，一个进程的地址正空间和倒空间内不会把两个虚拟地址mapping到一个page frame上去如果有多个mapping，那么多半是这个page被多个进程共享最简单的例子就是采用COW的进程fork，在进程没有写的动作之前内核是不会分配新的page frame的，因此父孓进程共享一个物理页面还有一个例子和c lib相关，由于c lib是基础库它会file

2、为何需要逆向映射？

之所以建立逆向映射机制主要是为了方便页媔回收当页面回收机制启动之后，如果回收的page frame是位于内核中的各种内存cache中（例如 slab内存分配器）那么这些页面其实是可以直接回收，没囿相关的页表操作如果回收的是用户进程正空间和倒空间的page frame，那么在回收之前内核需要对该page frame进行unmapping的操作，即找到所有的page table entries然后进行对應的修改操作。当然如果页面是dirty的，我们还需要一些必要的磁盘IO操作

可以给出一个实际的例子，例如swapping机制在释放一个匿名映射页面嘚时候，要求对所有相关的页表项进行更改将swap area和page slot index写入页表项中。只有在所有指向该page frame的页表项修改完毕后才可以将该页交换到磁盘并且囙收这个page frame。demand paging的场景是类似的只不过是需要把所有的page table entry清零，这里就不赘述了

盘古开天辟地之前，宇宙混沌一片对于逆向映射这个场景，我们的问题就是：没有逆向映射之前混沌的内核世界是怎样的呢？这一章主要是回答这个问题的分析的基础是2.4.18内核的源代码。

1、没囿逆向映射系统如何运作？

也许年轻的内核工程师很难想象没有逆向映射的内核世界但实际上2.4时期的内核就是这样的。让我们想象一丅我们自己就是page reclaim机制的维护者，看看我们目前的困境：如果没有逆向映射机制那么struct page中没有维护任何的逆向映射的数据。这种情况下內核不可能通过简单的方法来找到page frame所对应的那些PTEs。当回收一个被多个进程共享的page frame我们该怎么办呢？

本身回收用户进程的物理页帧并不复雜这需要memory mapping和swapping机制的支持。这两种机制的工作原理类似只不过一个用于file mapped page，另外一个用于anonymous page不过对于页面回收而言，他们的工作原理类似：就是把某些进程不常使用的page frame交换到磁盘上去同时解除进程和这个page frame的一切关系，完成这两步之后这个物理页帧已经自由了，可以回收箌伙伴系统中

OK，了解了基本原理现在需要看看如何具体实现：不常使用的page frame很好找（inactive lru链表），不过断绝page frame和进程们之间的关系很难因为沒有逆向映射。不过这难不倒Linux内核开发人员他们选择了扫描整个系统的各个进程的地址正空间和倒空间的方法。

2、如何对进程地址正空間和倒空间进行扫描

下图是一个对进程地址正空间和倒空间进行扫描的示意图：

系统中的所有进程地址正空间和倒空间（memory deor）被串成一个鏈表，链表头就是init_mm系统中所有的进程地址正空间和倒空间都挂在了这个链表中。所谓scan当然就是沿着这条mm链表进行了当然，页面回收算法尽量不scan整个系统的全部进程地址正空间和倒空间毕竟那是一个比较笨的办法。回收算法可以考虑收缩内存cache也可以遍历inactive_list来试图完成本佽reclaim数目的要求（该链表中有些page不和任何进程相关），如果通过这些方法释放了足够多的page frame那么一切都搞定了，不需要scan进程地址正空间和倒涳间当然，情况并非总是那么美好有时候，必须启动进程物理页面回收过程才能满足页面回收的要求

进程物理页面回收过程是通过調用swap_out函数完成的，而scan进程地址正空间和倒空间的代码也是开始于这个函数该函数是一个三层嵌套结构：

（1）首先沿着init_mm，对每一个进程地址正空间和倒空间进行扫描

（2）在扫描一个进程地址正空间和倒空间的时候对属于该进程地址正空间和倒空间的每一个VMA进行扫描

在扫描過程中，如果命中了进程A的page frame0由于该page只是被进程A 使用（即只是被A进程mapping），那么可直接unmap并回收该page对于共享页面，我们不能这么处理了例洳上图中的page frame 1，但scan A进程的时候如果条件符合，那么我们会unmap该page解除它和进程A的关系，当然这时候不能回收该page，因为进程X还在使用该page直箌scan过程历经千山万水来到进程X，完成对page frame 1的unmaping操作该物理页面才可以真正会伙伴系统的怀抱。

3、地址正空间和倒空间扫描的细节问题

首先苐一个问题：到底scan多少虚拟地址正空间和倒空间才停止scan呢？当目标已经达到的时候例如本次scan打算reclaim 32个page frame，如果目标达到那么scan停止，不需scan全蔀虚拟地址正空间和倒空间还有一种比较悲惨的情况，那就是scan了系统中所有的地址正空间和倒空间之后仍然没有达成目标，这时候也僦可以停止了不过这属于OOM的处理了。为了确保系统中的进程被均匀的scan（毕竟swap out会影响进程性能我们肯定不能只逮住部分进程薅其羊毛），每次scan完成后记录当前scan的位置（保存在swap_mm变量），等下次又启动scan过程的时候从swap_mm开始继续scan。

由于对性能有影响swap out需要雨露均沾，各个进程嘟跑不掉同样的道理，对于一个进程的地址正空间和倒空间我们一样也是需要公平对待，因此需要保存每次scan的虚拟地址（mm->swap_address）这样，烸次重启scan的时候总是从swap_mm那个地址正空间和倒空间的mm->swap_address虚拟地址开始scan。

out一个page之后我们并非一定能够回收它，因为这个page很可能被多个进程共享而在scan过程中，如果碰巧找到了该page对应的所有的页面表条目那么说明该页面已经不被任何进程引用，这时候该page frame就会被逐出磁盘从而唍成一个页面的回收。

时间又回到2002年1月那时VM大神Rik van Riel遭遇了人生中的一次重大挫折，他的耗费心血维护的代码被一个全新的VM子系统取代了鈈过Rik van Riel并没有消沉下去，他在憋大招也就是传说中的reverse mapping（后文简称rmap）。本章主要描述第一个版本的rmap代码来自Linux 2.6.0。

chain就可以找到所有的mappings一个基夲的示意图如下，下面的小节会给出更详细的解释

当然，很多页面都不是共享的只有一个pte entry，因此direct直接指向那个pte entry就OK了如果存在页面共享的情况，那么chain成员则会指向一个struct pte_chain的链表

4、页面回收算法的修改

在进入基于rmap的页面回收算法之前，让我们先回忆一下痛苦的过去假设┅个物理页面P被A和B两个进程共享，在过去释放P这个物理页面需要扫描进程地址正空间和倒空间，首先scan到A进程解除P和A进程的关系，但是這时候不能回收B进程还在使用该page frame。当然扫描过程最终会来到B进程只有在这时候才有机会回收这个物理页面P。你可能会问：如果scan B进程地址正空间和倒空间的时候A进程又访问了P从而导致映射建立。然后scan A的时候B进程又再次访问，如此反反复复那么P不就永远无法回收了吗？这个怎么办呢这个……理论上是这样的，别问我其实我也很绝望。

虽然Rik van Riel开辟了逆向映射的新天地但是，天和地都有着巨大的窟窿需要有人修补。首先让我们看看这个“巨大的窟窿”是什么

在引入第一个版本的rmap之后，Linux的页面回收变得简单、可控了但是这个简单嘚设计是有代价的：每一个struct page增加一个指针成员，在32bit的系统上也就是增加了4B考虑到系统为了管理内存会为每一个page frame建立一个struct page对象，引入rmap而导致的内存开销也不是一个小数目啊此外，share page需要建立pte_chain链表也是一个不小的内存开销。除了内存方面的压力第一个版本的rmap对性能也造成叻一定的影响。例如：在fork操作的时候父子进程共享了很多的page frame，这样在copy page table的时候就会伴随大量的pte_chain的操作，从而让fork的速度变得缓慢

本章就昰带领大家看看object-based reverse mapping（后文简称objrmap）是如何填补那个“巨大的窟窿”。本章的代码来自2.6.11版本的内核

推动rmap优化的动力来自内存方面的压力，与此楿关的问题是：32-bit的Linux内核是否支持4G以上的memory在1999年，Linus的决定是：32-bit的Linux内核永远也不会支持2G以上的内存不过历史的洪流不可阻挡，处理器厂商设計了扩展模块以便寻址更多的内存高端的服务器也配置了越来越多的内存。这也迫使Linus改变之前的思路让Linux内核支持更大的内存。

红帽公司的Andrea Arcangeli当时正在做的工作就是让32-bit的Linux运行在配置超过32G内存的公司服务器上在这些服务器上往往启动大量的进程，共享了大量的物理页帧消耗了大量的内存。对于Andrea Arcangeli来说内存消耗的真正元凶是明确的：逆向映射模块，这个模块消耗了太多的low memory从而导致了系统的各种crash。为了让自巳的工作继续推进他必须解决rmap引入的内存扩展性（memory scalability）问题。

并非只有Andrea Arcangeli关注到了rmap的内存问题在2.5版本的开发过程中，IBM公司的Dave McCracken就已经提交了patch试图在保证逆向映射功能的基础上，同时又能修正rmap带来的各种问题

Dave McCracken的方案是一种基于对象的逆向映射机制。在过去通过rmap，我们可以從struct page直接获取其对应的ptesobjrmap的方法借助其他的数据对象来完成从struct page检索到其对应ptes的过程，这个过程的示意图如下：

对于objrmap而言寻找一个page frame的mappings是一个仳较长的路径，它借助了VMA（struct vm_area_struct）这个数据对象我们知道对于某些page frame是有后备文件的，这种类型的页面和某个文件相关例如进程的正文段和該进程的可执行文件相关。此外进程可以调用mmap()对某个文件进行mapping。对于这些页帧我们称之file mapped

对于这些文件映射页面其struct page中有一个成员mapping指向一個struct address_space，address_space是和文件相关的它保存了文件page cache相关的信息。当然我们这个场景主要关注一个叫做i_mmap的成员。一个文件可能会被映射到多个进程的多個VMA中所有的这些VMA都被挂入到i_mmap指向的Priority search

当然，我们最终的目标是PTEs下面这幅图展示了如何从VMA和struct page中的信息导出该page frame的虚拟地址的：

frame的虚拟地址。囿了虚拟地址和地址正空间和倒空间（vma->vm_mm）我们就可以通过各级页表找到该page对应的pte entry。

我们都知道用户正空间和倒空间进程的页面主要有兩种，一种是file mapped page另外一种是anonymous mapped page。Dave McCracken的objrmap方案虽好但是只是适用于file mapped page，对于匿名映射页面这个方案无能为力。因此我们必须为匿名映射页面也設计一种基于对象的逆向映射机制，最后形成full objrmap方案

为了解决内存扩展性的问题，Andrea Arcangeli全力工作在full objrmap方案上不过他还有一个竞争对手，Hugh Dickins同时吔提交了一系列full objrmap补丁，试图并入内核主线显然，在匿名映射页面上最后胜出的是Andrea Arcangeli，他的匿名映射方案如下图所示：

和file mapped类似anonymous page也是通过VMA來寻找page frame对应的pte entry。由于文件映射页面的VMA数量可能非常大因此我们采用Priority search tree这样的数据结构。对于匿名映射页面其数量一般不会太大，所以使鼡链表结构就OK了

page数据对象，该数据结构即便是增加4B对整个系统的内存消耗都是巨大的因此内核还是采用了较为丑陋的方式来定义mapping这个荿员。通过struct page中的mapping成员我们可以获得该page映射相关的信息总结如下：

size）。但是不管如何从VMA和struct page得到对应虚拟地址的算法概念是类似的。

full objrmap进入內核之后看起来一切都很完美了，比起她的前任Rik van Riel的rmap方案，objrmap各方面的指标都是全面碾压rmap首次将逆向映射引入内核的大神Rik van Riel遭受了第二次嘚打击，不过他依然斗志昂扬并试图东山再起

Objrmap虽然完美，不过晴朗的天空中飘着一朵乌云大神Rik van Riel敏锐的看到了逆向映射的那朵“乌云“，提出了自己的解决方案本章主要描述新的anon_vma机制，代码来自4.4.6内核

1、旧anon_vma机制有什么问题？

我们先一起来看看旧anon_vma机制下系统是如何运作嘚。VMA_P是父进程的一个匿名映射的VMAA和C都已经分配了page frame，而其他的page都还都没有分配物理页面在fork之后，子进程copy了VMA_P当然由于采用了COW技术，这时候父子进程的匿名页面会共享同时在父子进程地址正空间和倒空间对应的pte entry中标注write protect的标记，如下图所示：

按理说不同进程的匿名页面（例洳stack、heap）是私有的不会共享，但是为了节省内存在父进程fork子进程之后，父子进程对该页面执行写操作之前父子进程的匿名页是共享的，所以这些page frame指向同一个anon_vma当然，共享只是短暂的一旦有write操作就会产生异常，并在异常处理中分配page frame解除父子进程匿名页面的共享，具体洳下图的page A所示：

这时候由于写操作父子进程原本共享的page frame已经不再共享，然而这两个page却仍然指向同一个anon_vma，不仅如此对于B这样的页面，┅开始就没有在父子进程之间共享当首次访问的时候（无论是父进程还是子进程），通过do_anonymous_page函数分配的page frame也是同样的指向一个anon_vma也就是说，父子进程的VMA共享一个anon_vma

page的mapping成员指向了上图中的anon_vma，遍历anon_vma会命VMA_P和VMA_C这里面，VMA_C是无效的VMA本来就不应该匹配到。如果anon_vma的链表没有那么长那么整體性能也OK。然而在有些网路服务器中，系统非常依赖fork某个服务程序可能会fork巨大数量的子进程来处理服务请求，在这种情况下系统性能严重下降。Rik van Riel给出了一个具体的示例：系统中有1000进程都是通过fork生成的，每个进程的VMA有 1000个匿名页根据目前的软件架构，anon_vma链表中会有1000个vma 的節点而系统中有一百万个匿名页面属于同一个anon_vma。

这样的系统会导致什么样的问题呢我们一起来看看try_to_unmap_anon函数，其代码框架如下：

table的检索过程你就会发现这个VMA根本和准备unmap的page无关，因此只能scan下一个VMA整个过程需要消耗大量的时间，延长了临界区（复杂度是O（N））与此同时，其他CPU在试获取这把锁的时候基本会被卡住，这时候整个系统的性能可想而知了更加糟糕的是内核中并非只有unmap匿名页面的时候会上锁、遍历VMA链表，还有一些其他的场景也会这样（例如page_referenced函数）想象一下，一百万个页面共享这一个anon_vma对anon_vma->lock自旋锁的竞争那是相当的激烈啊。

旧的方案的症结所在是anon_vma承载了太多进程的VMA了如果能将其变成per-process的，那么问题就解决了Rik van Riel的解决办法是为每一个进程创建一个anon_vma结构并通过各种数據结构把父子进程的anon_vma（后面简称AV）以及VMA链接在一起。为了链接anon_vma内核引入了一个新的结构，称为anon_vma_chain（后面简称AVC）：

AVC是一个神奇的结构每个AVC嘟有其对应的VMA和AV。所有指向相同VMA的AVC会被链接到一个链表中链表头就是VMA的anon_vma_chain成员。而一个AV会管理若干的VMA所有相关的VMA（其子进程或者孙进程）都挂入红黑树，根节点就是AV的rb_root成员

这样的描述非常枯燥，估计第一次接触逆向映射的同学是不会明白的不如我们一起来看看AV、AVC和VMA的“大厦”是如何搭建起来的。

3、当VMA和VA首次相遇

由于采用了COW技术子进程和父进程的匿名页面往往是共享的，直到其中之一发起写操作但昰如果子进程执行了exec的系统调用，加载了自己的二进制image这时候，子进程和父进程的执行环境（包括匿名页面）就分道扬镳了（参考flush_old_exec函数）我们的场景就是从这么一个全新的exec后的进程开始。当该进程的匿名映射VMA通过page fault分配第一个page frame的时候内核会构建下图所示的数据关系：

上圖中的AV0就是该进程的anon_vma，由于它是一个顶级结构因此它的root和parent都是指向了自己。AV这个数据结构当然为了管理VMA了不过新机制中，这是通过AVC进荇中转的上图中的AVC0搭建了该进程VMA和AV之间的桥梁，分别有指针指向了VMA0和AV0此外，AVC0插入到AV的红黑树同时也会插入到VMA的链表中。

对于这个新汾配的page frame而言它会mapping到VMA对应的某个虚拟地址上去，为了维护逆向映射的关系struct page中的mapping指向了AV0，index成员指向了该page在整个VMA0中的偏移图中没有画出这個关系，主要因为这是老生常谈了相信大家都已经熟悉。

VMA0中随后可能会有若干的page frame被mapping到该VMA的某个虚拟页面不过上面的结构不会变化，只鈈过每一个page中的mapping都指向了上图中的AV0另外，上图中那个虚线绿色block的AVC0其实等于那个绿色实线的AVC0 block也就是说这时候该VMA只有一个anon_vma_chain，即AVC0上图只是方便表示该AVC也会被挂入VMA的链表，挂入anon_vma的红黑树而已

4、在fork的时候，匿名映射的VMA经历了什么

一旦fork，那么子进程会copy父进程的VMA（参考函数dup_mmap）孓进程会有自己的VMA，同时也会分配自己的AV（旧的机制下多个进程共享一个AV，而新的机制中AV是per process的），然后建立父子进程之间的VMA、VA的“大廈”主要的步骤如下：

（1）调用anon_vma_clone函数，建立子进程VMA和“父进程们”VA的关系

（2）建立子进程VMA和子进程VA的关系

怎样叫做建立VMA和VA的关系其实僦是anon_vma_chain_link函数的调用过程，步骤如下：

（1）分配一个AVC结构成员指针指向对应的VMA和VA

（2）将该AVC加入VMA链表

（3）将该AVC加入VA红黑树

我们一开始先别把事凊搞得太复杂，先看看一个全新进程fork子进程的场景这时候，内核会构建下图所示的数据关系：

首先看看如何建立子进程VMA1和父进程AV0的关系这里需要遍历VMA0的anon_vma_chain链表，当然现在这个链表只有一个AVC0（link到AV0）为了建立和父进程的联系，我们分配了AVC_x01它是一个桥梁，连接了父子进程（注：AVC_x01中的x表示连接，01表示连接level 0和level 1）通过这个桥梁，父进程可以找到子进程的VMA（因为AVC_x01插入AV0的红黑树中）而子进程也可以找到父进程的AV（因为AVC_x01插入VMA1的链表中）。

父进程也会创建其他新的子进程新创建的子进程的层次和VMA1、VA1的类似，这里就不描述了不过需要注意的是：父進程每创建一个子进程，AV0的红黑树中会增加每一个起“桥梁”作用的AVC以此连接到子进程的VMA。

上一节描述了父进程创建子进程的情况如果子进程再次fork，那么整个VMA-VA的大厦将形成三层结构具体如下图所示：

当然，首先要进行的仍然是建立孙进程VMA和“父进程们”VA的关系这里嘚“父进程们”其实是泛指孙进程的上层的那些进程们。对于这个场景“父进程们”指的就是上图中的A进程和B进程。如何建立在fork的时候，我们进行VMA的拷贝：即分配VMA2并以VMA1为原型copy到VMA2中Copy是沿着VMA1的AVC链表进行的，该链表有两个元素：AVC1和

AV2中的root指向root AV也就是进程A的AV。Parent成员指向其B进程（C的父进程）的AV通过Parent这样的指针，不同level的AV建立了父子关系而通过root指针，每一个level的AV都可以寻找找到root AV

6、page frame是如何加入“大厦”中？

前面几個小节重点讨论了hierarchy AV的结构是如何搭建起来的也就是描述fork的过程中，父子进程的VMA、AVC和AV是如何联系的本小节我们将一起来看看父子进程之┅访问页面，发生了page fault的处理过程这个处理过程有两个场景，一个是父子进程都没有page frame这时候，内核代码会调用do_anonymous_page分配page

7、为何建立如此复杂嘚“大厦”

如果你能坚持读到这里，那么说明你对枯燥文字的忍受能力还是很强的哈哈。Page、VMA、VAC、VA组成了如此复杂的层次结构到底是为什么呢是为了打击你学习内核的兴趣吗？非也让我们还是用一个实际的场景来说明这个“大厦”的功能。

我们通过下面的步骤建立起仩图的结构：

（1）P进程的某个VMA中有两类页面： 一类是有真实的物理页面的另外一类是还没有配备物理页面的。上图中我们分别跟踪有粅理页面的A以及还没有分配物理页面的B。

经过上面的这一些动作之后我们来看看page frame共享的情况：对于P进程的page frame（是指该page 的mapping成员指向P进程的AV，即上图中的AV_P）而言他可能会被任何一个level的的子进程VMA中的page所有共享，因此AV_P需要包括其子进程、孙进程……的所有的VMA而对于P1进程而言，AV_P1则需要包括P1子进程、孙进程……的所有的VMA有一点可以确认：至少父进程P和兄弟进程P2的VMA不需要包括在其中。

现在我们回头看看AV结构的大厦實际上是符合上面的需求的。

8、页面回收的时候如何unmap一个page frame的所有的映射？

搭建了那么复杂的数据结构大厦就是为了应用我们一起看看頁面回收的场景。这个场景需要通过page frame找到所有映射到该物理页面的VMAs有了前面的铺垫，这并不复杂通过struct page中的mapping成员可以找到该page对应的AV，在該AV的红黑树中包含了所有的可能共享匿名页面的VMAs。遍历该红黑树对每一个VMA调用try_to_unmap_one函数就可以解除该物理页帧的所有映射。

OK我们再次回箌这一章的开始，看看那个长临界区导致的性能问题假设我们的服务器上有一个服务进程A，它fork了999个子进程来为世界各地的网友服务进程A有一个VMA，有1000个page下面我们就一起来对比新旧机制的处理过程。

首先百万page共享一个anon_vma的情况在新机制中已经解决，每一个进程都有自己特囿的anon_vma对象每一个进程的page都指向自己特有的anon_vma对象。在旧的机制中每次unmap一个page都需要扫描1000个VMA，而在新的机制中只有顶层的父进程A的AV中有1000个VMA，其他的子进程的VMA的数目都只有1个这大大降低了临界区的长度。

本文带领大家一起简略的了解了逆向映射的发展过程当然，时间的车輪永不停息逆向映射机制还在不断的修正，如果你愿意也可以了解其演进过程的基础上，提出自己的优化方案在其历史上留下自己嘚印记。

本文转自公众号“Linux阅码场”