动态内存管理：Linux下的高效内存回收方法-51CTO.COM

在 Linux 系统的庞大体系中，内存扮演着举足轻重的角色，堪称系统运行的 “血液”。它是计算机的关键部件，如同一个高速运转的临时仓库，暂时存放着 CPU 中的运算数据，以及与硬盘等外部存储器交换的数据，是外部存储与 CPU 沟通的重要桥梁。

只要 Linux 系统开始运行，操作系统就会如同勤劳的搬运工，将需要运算的数据从内存精准地调到 CPU 中进行运算。当运算圆满完成后，CPU 又会迅速地将结果传送出来。可以说，内存的运行状况直接决定了计算机整体运行的快慢程度，影响着整个系统的性能表现。就像人体的血液循环，如果血液流动不畅，身体各个器官就无法获得充足的养分，进而导致身体机能下降。同样，在 Linux 系统中，若内存管理出现问题，系统的运行效率也会大幅降低，甚至可能引发系统崩溃等严重后果。

一、内存回收概述

在 Linux 系统中，内存回收机制就像是一位默默守护系统的 “内存管家”，肩负着至关重要的职责。它的主要任务是在系统运行过程中，对内存资源进行有效的管理和回收，确保内存的合理利用，维持系统的稳定运行。

当系统中的内存资源变得紧张时，内存回收机制就会迅速启动，开始筛选那些暂时不用或者可以被释放的内存空间。比如，有些进程可能已经完成了当前的任务，处于闲置状态，但它们占用的内存却没有被及时释放。这时，内存回收机制就会将这些闲置进程占用的内存回收回来，重新分配给那些急需内存的新进程，就像一位精明的管家，合理调配家中的资源，让每一份资源都能物尽其用。

从性能角度来看，内存回收机制对系统的高效运行起着关键作用。假设没有这个机制，随着系统中进程的不断启动和停止，内存中会逐渐积累大量被闲置进程占用的内存碎片。这些碎片就像一个个零散的小空间，难以满足新进程对连续内存空间的需求，导致新进程在申请内存时，需要花费大量时间寻找合适的内存块，从而使系统响应变得迟缓，运行效率大幅降低。例如，在服务器环境中，如果内存回收不及时，当大量用户同时访问服务器时，新的服务请求可能因为无法及时获得足够的内存资源而被延迟处理，严重影响用户体验。

在稳定性方面，内存回收机制更是系统的 “稳定器”。如果内存一直处于高占用且无法回收的状态，系统就如同一个被过度填充的容器，随时可能出现崩溃等严重问题。比如，在长时间运行的数据库服务器中，如果内存持续被无效占用，当达到一定程度时，数据库可能会因为无法分配到足够的内存来处理事务而出现异常，甚至导致整个服务器死机，造成巨大的损失。

二、Linux内存回收机制

2.1内存回收的主要对象

在 Linux 内存回收机制的精密体系中，内存回收主要聚焦于匿名页和文件页这两大关键对象，它们就像是内存世界中的两类不同 “居民”，有着各自独特的 “生存法则” 和回收方式。

匿名页，作为内存中的一类特殊存在，如同漂泊的 “游子”，没有对应的磁盘文件作为坚实 “后盾”。进程中的堆、栈数据等便是匿名页的典型代表。在内存回收的关键时刻，系统这位 “精明的管家” 会仔细筛选出那些活跃度较低、不经常被访问的匿名页。这些被选中的匿名页就像暂时被 “请出家门”，被写入到 swap 分区这个特殊的 “临时住所” 中。经过这样的处理后，它们就可以作为空闲页框被释放到伙伴系统中，如同重新获得自由的资源，等待着被其他进程申请使用，再次投入到系统运行的 “工作” 中。

而文件页，则像是有 “固定住所” 的居民，它涵盖了内核缓存的磁盘数据（Buffer）以及内核缓存的文件数据（Cache）等，与磁盘文件有着紧密的联系。在回收文件页时，系统同样会运用一套筛选机制，找出那些不常被访问的页面。如果这个文件页中保存的内容与磁盘中文件对应内容完全一致，就如同一个整洁有序、与外界保持同步的 “房间”，那么它就是一个干净的文件页。

这种情况下，就不需要进行繁琐的回写磁盘操作，直接将其作为空闲页框释放到伙伴系统中，实现资源的快速回收和再利用。但要是文件页保存的数据和磁盘中文件对应的数据不一致，就像一个 “房间” 内部发生了变化却还未与外界同步，那么这个文件页就被认定为脏页。此时，就需要先将此文件页回写到磁盘中对应数据所在的位置上，完成数据的同步更新，然后才可以把它作为空闲页框释放到伙伴系统中。通过这样有针对性的回收处理，当内存回收完成后，系统空闲的页框数量就会增加，进而有效缓解内存压力，保障系统能够相对稳定且高效地运行下去。

2.2以 zone 为单位的内存回收规则

内存回收是以zone为单位进行的(也会以memcg为单位，这里不讨论这种情况)，而系统判断一个zone需不需要进行内存回收，如上面所说，为zone设置一条线，当此zone的空闲页框不足以到达这条线时，就会对此zone进行内存回收，实际上一个zone有三条线，这三条线分别是最小阀值(WMARK_MIN)，低阀值(WMARK_LOW)，高阀值(WMARK_HIGH)，它们都保存在zone的watermark[NR_WMARK]数组中，这个数组中保存的是各个阀值要求的页框数量，而每个阀值都会对内存回收造成影响。而它们的描述如下：

watermark[WMARK_MIN](min阀值)：在快速分配失败后的慢速分配中会使用此阀值进行分配，如果慢速分配过程中使用此值还是无法进行分配，那就会执行直接内存回收和快速内存回收
watermark[WMARK_LOW](low阀值)：也叫低阀值，是快速分配的默认阀值，在分配内存过程中，如果zone的空闲页框数量低于此阀值，系统会对zone执行快速内存回收
watermark[WMARK_HIGH](high阀值)：也叫高阀值，是zone对于空闲页框数量比较满意的一个值，当zone的空闲页框数量高于这个值时，表示zone的空闲页框较多。所以对zone进行内存回收时，目标也是希望将zone的空闲页框数量提高到此值以上，系统会使用此阀值用于oomkill进行内存回收。

这三个阀值的关系是：min阀值 < low阀值 < high阀值。在系统初始化期间，根据系统中整个内存的数量与每个zone管理的页框数量，计算出每个zone的min阀值，然后low阀值 = min阀值 + (min阀值 / 4)，high阀值 = min阀值 + (min阀值 / 2)。这样就得出了这三个阀值的数值，我们可以通过/proc/zoneinfo中查看这三个阀值的数值：

图片

可以很明显看出来，相对于整个zone管理的总页框数量(managed)，这三个值是非常非常小的，连managed的1%都不到，这些都是在系统初始化期间进行设置的，具体设置函数是__setup_per_zone_wmarks()。有兴趣的可以去看看。这个阀值对内存回收的进行具有很重要的意义，后面会详细进行说明。

对于zone的内存回收，它针对三样东西进程回收：slab、lru链表中的页、buffer_head。这里只讨论内存回收针对lru链表中的页是如何进行回收的。lru链表主要用于管理进程空间中使用的内存页，它主要管理三种类型的页：匿名页、文件页以及shmem使用的页。在内存回收过程中，说简单些，就是将lru链表中的一些页数据放到磁盘中，然后将这些页释放，当然实际上可没有那么简单，这个后面会详细说明。

在说内存回收前，要先补充一些知识，因为内存回收并不是一个孤立的功能，它内部会涉及到其他很多东西，比如内存分配、lru链表、反向映射、swapcache、pagecache等。

(1)页描述符页描述符中对内存回收来说非常必要的标志：

PG_lru：表示页在lru链表中
PG_referenced: 表示页最近被访问(只有文件页使用)
PG_dirty：页为脏页，文件页被修改，以及非文件页加入到swap cache后，就会被标记为脏页。在此页回写前会被清除，但是回写失败时又会被置位
PG_active：页为活动页，配合PG_lru就可以得出页是处于非活动页lru链表还是活动页lru链表
PG_private：页描述符中的page->private保存有数据
PG_writeback：页正在进行回写
PG_swapbacked：此页可写入swap分区，一般用于表示此页是非文件页
PG_swapcache：页已经加入到了swap cache中(只有非文件页使用)
PG_reclaim：页正在进行回收，只有在内存回收时才会对需要回收的页进行此标记
PG_mlocked：页被锁在内存中

在内核中，只有一种页能够进行回收，就是页描述符中的_count为0的页，每个页都有自己唯一的页描述符，而每个页描述符中都有一个_count，这个_count代表的是此页的引用计数，当_count为-1时，说明此页是空闲的，存放在伙伴系统中，每当有一个进程映射了此页时，此页的_count就会++，也就是当某个页被10个进程映射了，它的page->_count肯定大于10(不等于10是因为可能还有其他模块引用了此页，比如块层、驱动等)，所以也可以反过来说，如果某个页的page->_count == 0，那就说明此页可以直接释放回收了。

也就是说，内核实际上回收的是那些page->_count == 0的页，但是如果真的是这样，内存回收这就没有任何意义了，因为当最后一个引用此页的模块释放掉此页的引用时，如果page->_count为0，肯定会释放回收此页的。实际上内存回收做的事情，就是想办法将一些page->_count不为0的页，尝试将它们的page->_count降到0，这样系统就可以回收这些页了。

下面是我总结出来在内存回收过程中会对页的page->_count产生影响的操作：

一个进程映射此页，page->_count++
一个进程取消映射此页，page->_count--
此页加入到lru缓存中，page->_count++
此页从lru缓存加入到lru链表中，page->_count--
此页被加入到一个address_space中，page->_count++
此页从address_space中移除时，page->_count--
文件页添加了buffer_heads，page->_count++
文件页删除了buffer_heads，page->_count--
swap分区

2.3lru链表

lru链表主要作用就是将页排序，将最应该回收的页放到最后面，最不应该回收的页放到最前面，，然后进行内存回收时，就会从后面向前面进行扫描，将扫描到的页尝试进行回收。这里只需要记住一点，回收的页都是非活动匿名页lru链表或者非活动文件页lru链表上的页。这些页包括：进程堆、栈、匿名mmap共享内存映射、shmem共享内存映射使用的页、映射磁盘文件的页。

首先先说明一下页描述符中对内存回收来说非常必要的标志：

PG_lru：表示页在lru链表中
PG_referenced: 表示页最近被访问(只有文件页使用)
PG_dirty：页为脏页，文件页被修改，以及非文件页加入到swap cache后，就会被标记为脏页。在此页回写前会被清除，但是回写失败时又会被置位
PG_active：页为活动页，配合PG_lru就可以得出页是处于非活动页lru链表还是活动页lru链表
PG_private：页描述符中的page->private保存有数据
PG_writeback：页正在进行回写
PG_swapbacked：此页可写入swap分区，一般用于表示此页是非文件页
PG_swapcache：页已经加入到了swap cache中(只有非文件页使用)
PG_reclaim：页正在进行回收，只有在内存回收时才会对需要回收的页进行此标记
PG_mlocked：页被锁在内存中（此标志可以保证不被换出，但是无法保证不被被做
内存迁移）

内存回收做的事情就是想办法将目标页的page->_count降到0，对于那些没有进程映射了页，释放起来就很简单，如果页映射了磁盘文件，并且页为脏页(被写过)，那就就把页中的数据回写到磁盘中映射的文件中，而如果页没有映射磁盘文件，那么直接释放即可。但是对于有进程映射的页，如果此页映射了磁盘文件，并且页为脏页，那么和之前一样，将此页进行回写，然后释放回收即可，但是此页没有映射磁盘文件，情况就会稍微复杂，会将页数据写入到swap分区中，然后将此页释放回收。总结如下：

干净页，并且映射了磁盘文件的页，直接回收
脏页(PG_dirty置位)，回写到对应磁盘文件中，然后回收
没有进程映射，并且没有映射磁盘文件的页，直接回收
有进程映射，并且没有映射磁盘文件的页，回写到swap分区中，然后回收

接下来会分为非活动匿名页lru链表的页的换入换出，非活动文件页lru链表的页的换入换出进行描述。

匿名页lru链表上保存的页为：进程堆、栈、数据段，匿名mmap共享内存映射，shmem映射。这些类型的页都有个特点，在磁盘上没有映射对应的文件(shmem有对应的文件，是/dev/zero，但它不是映射此设备文件)。而在内存回收时，会从非活动匿名页lru链表末尾向前扫描一定数量的页框，然后尝试将这些页框进行回收，而如果这些页框没有进程映射它们，那么它们可以直接释放，而如果有进程映射了它们，那么系统就必须将这些页框回写到磁盘上。

在linux系统中，你可以给系统挂载一个swap分区，这个分区就是专门用于保存这些类型的页的。当这些页需要回收，并且有进程映射了它们时，系统就会将这些页写入swap分区，需要注意，它们需要回收只有在内存不足进行内存回收时才会发生，也就是当系统内存充足时，是不会将这些类型的页写入到swap分区中的(使用memcg除外)，在磁盘上，一个swap分区是一组连续的物理扇区，比如一个1G大小的swap分区，那么它在磁盘上会占有1G大小磁盘块，然后这块磁盘块的第一个4K，专门用于存swap分区描述结构的，而之后的磁盘块，会被划分为一个一个4K大小的页槽(正好与普通页大小一致)，然后将它们标以ID，如下：

图片

每个页槽可以保存一个页的数据，这样，一个被换出的页就可以写入到磁盘中，系统也能够将这些页组织起来了。虽然是叫swap分区，但是内核似乎并不将swap分区当做一个磁盘分区来看待，更像的是将其当做一个文件来看待，因为这个，每个swap分区都有一个address_space结构，这个结构是每个磁盘文件都会有一个的，这个address_space结构中最重要的是有一个基树和一个address_space操作集。

而这里swap分区有一个，swap分区的address_space叫做swap cache，它的作用是从非文件页在回写到swap分区到此非文件页被回收前的这段时间里，起到一个将swap类型的页表项与此页关联的作用和同步的作用。在这个swap cache的基树中，将此swap分区的所有页槽组织在了一起。当非活动匿名页lru链表中的一个页需要写入到swap分区时，步骤如下：

swap分配一个空闲的页槽
根据这个空闲页槽的ID，从swap分区的swap cache的基树中找到此页槽ID对应的结点，将此页的页描述符存入当中
内核以页槽ID作为偏移量生成一个swap页表项，并将这个swap页表项保存到页描述符中的private中
对页进行反向映射，将所有映射了此页的进程页表项改为此swap页表项
将此页的mapping改为指向此swap分区的address_space，并将此页设置为脏页
通过swap cache中的address_space操作集将此页回写到swap分区中
回写完成
此页要被回收，将此页从swap cache中拿出来

当一个进程需要访问此页时，系统则会将此页从swap分区换入内存中，具体步骤如下：

一个进行访问了此页，会先访问到之前设置的swap页表项
产生缺页异常，在缺页异常中判断此页在swap分区中，而不在内存中
分配一个新页
根据进程的页表项中的swap页表项找到对应的页槽和swap cache
如果以页槽ID在swap cache中没有找到此页，说明此页已被回收，从分区中将此页读取进来
如果以页槽ID在swap cache中找到了此页，说明此页还在内存中，还没有被回收，则直接映射此页

这样再此页没有被换出或者正在换出的情况下，所有映射了此页的进程又可以重新访问此页了，而当此页被完全换出到swap分区然后被回收后，此页就会从swap cache中移除，之后如果进程想要访问此页，就需要等此页被完全换入之后才行了。也就是这个swap cache完全为了提高效率，在页没有被回收前，即使此页已经回写到swap分区了，只要有进映射此页，就可以直接映射内存中的页，而不需要将页从磁盘读进来。对于非活动匿名页lru链表上的页进行换入换出这里就算是说完了。记住对于非活动匿名页lru链表上的页来说，当此页加入到swap cache中时，那么就意味着这个页已经被要求换出，然后进行回收了。

但是相反文件页则不是这样，接下来简单说说映射了磁盘文件的文件页的换入换出，实际上与非活动匿名页lru链表上的页进行换入换出是一模一样的，因为每个磁盘文件都有一个自己的address_space，这个address_space就是swap分区的address_space，磁盘文件的address_space称为page cache，接下来的处理就是差不多的，区别为以下三点：

对于磁盘文件来说，它的数据并不像swap分区这样是连续的。
当文件数据读入到一个页时，此文件页就需要在文件的page cache中做关联，这样当其他进程也需要访问文件的这块数据时，通过page cache就可以知道此页在不在内存中了。
并不会为映射了此文件页的进程页表项生成一个新的页表项，会将所有映射了此页的页表项清空，因为在缺页异常中通过vma就可以判断发生缺页的页是映射了文件的哪一部分，然后通过文件系统可以查到此页在不在内存中。而对于匿名页的vma来说，则无法做到这一点。

2.4内存分配过程

要说清楚内存回收，就必须要先理清楚内存分配过程，在调用alloc_page()或者alloc_pages()等接口进行一次内存分配时，最后都会调用到__alloc_pages_nodemask()函数，这个函数是内存分配的心脏，对内存分配流程做了一个整体的组织。主要需要注意的，就是在__alloc_pages_nodemask()中会进行一次使用low阀值的快速内存分配和一次使用min阀值的慢速内存分配，快速内存分配使用的函数是get_page_from_freelist()，这个函数是分配页框的基本函数，也就是说，在慢速内存分配过程中，收集到和足够数量的页框后，也需要调用这个函数进行分配。先简单说明快速内存分配和慢速内存分配：

快速内存分配：是get_page_from_freelist()函数，通过low阀值从zonelist中获取合适的zone进行分配，如果zone没有达到low阀值，则会进行快速内存回收，快速内存回收后再尝试分配。
慢速内存分配：当快速分配失败后，也就是zonelist中所有zone在快速分配中都没有获取到内存，则会使用min阀值进行慢速分配，在慢速分配过程中主要做三件事，异步内存压缩、直接内存回收以及轻同步内存压缩，最后视情况进行oom分配。并且在这些操作完成后，都会调用一次快速内存分配尝试获取页框。

通过以下这幅图，来说明流程：

图片

说到内存分配过程，就必须要说说中的preferred_zone和zonelist，preferred_zone可以理解为内存分配时，最希望从这个zone进行分配，而zonelist理解为，当没办法从preferred_zone分配内存时，则根据zonelist中zone的顺序尝试进行分配，为什么会有这两个参数，是因为numa架构导致的，我们知道，当有多个node结点时，CPU跨结点访问内存是效率比较低的工作，所以CPU会优先在本node上的zone进行内存分配工作，如果本node上实在分配不出内存，那就尝试在离本node最近的node上分配，如果还是无法分配到，那就找再下一个node。

这样每个node会将其他node的距离进行一个排序形成了其他node的一个链表，这个链表越前面的node就表示里本node越近，越后面的node就离本node越远。而在32位系统中，每个node有3个zone，分别是ZONE_HIGHMEM、ZONE_NORMAL、ZONE_DMA。每个区管理的内存数量不一样，导致每个区的优先级不同，优先级为ZONE_HIGHMEM > ZONE_NORMAL > ZONE_DMA，对于进程使用的页，系统优先分配ZONE_HIGHMEM的页框，如果ZONE_HIGHMEM无法分配页框，则从ZONE_NORMAL进行分配，当然，对于内核使用的页来说，大部分只会从ZONE_NORMAL和ZONE_DMA进行分配，这样，将这个zone优先级与node链表结合，就得到zonelist链表了，比如对于node0，它完整的zonelist链表就可能如下：

node0的管理区                                                                       node1的管理区

　　ZONE_HIGHMEM(0) -> ZONE_NORMAL(0) -> ZONE_DMA(0) -> ZONE_HIGHMEM(1) -> ZONE_NORMAL(1) -> ZONE_DMA(1)

因为每个node都有自己完整的zonelist链表，所以对于node1，它的链表时这样的

　　node1的管理区                                                                       node0的管理区

　　ZONE_HIGHMEM(1) -> ZONE_NORMAL(1) -> ZONE_DMA(1) -> ZONE_HIGHMEM(0) -> ZONE_NORMAL(0) -> ZONE_DMA(0)

　　这样得到了两个node自己的zonelist，但是在内存分配中，还不一定会使用node自己的zonelist，因为有些内存只希望从ZONE_NORMAL和ZONE_DMA中进行分配，所以，在每次进行内存分配时，都会此次内存分配形成一个满足的zonelist，比如：某次内存分配在node0的CPU上执行了，希望从ZONE_NORMAL和ZONEDMA区中进行分配，那么就会形成下面这个链表

　　node0的管理区                                      node1的管理区

　　ZONE_NORMAL(0) -> ZONE_DMA(0) -> ZONE_NORMAL(1) -> ZONE_DMA(1)

　　这样就是preferred_zone和zonelist，preferred_zone一般都是指向zonelist中的第一个zone，当然这个还会跟nodemask有关，这个就不细说了。1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.

2.5扫描控制结构

扫描控制结构用于内存回收和内存压缩，它的主要作用时保存对一次内存回收或者内存压缩的变量和参数，一些处理结果也会保存在里面，结构如下：

/* 扫描控制结构，用于内存回收和内存压缩 */
struct scan_control {
    /* 需要回收的页框数量 */
    unsigned long nr_to_reclaim;

    /* 申请内存时使用的分配标志 */
    gfp_t gfp_mask;

    /* 申请内存时使用的order值，因为只有申请内存，然后内存不足时才会进行扫描 */
    int order;

    /* 允许执行扫描的node结点掩码 */
    nodemask_t    *nodemask;

    /* 目标memcg，如果是针对整个zone进行的，则此为NULL */
    struct mem_cgroup *target_mem_cgroup;

    /* 扫描优先级，代表一次扫描(total_size >> priority)个页框 
     * 优先级越低，一次扫描的页框数量就越多
     * 优先级越高，一次扫描的数量就越少
     * 默认优先级为12
     */
    int priority;

    /* 是否能够进行回写操作(与分配标志的__GFP_IO和__GFP_FS有关) */
    unsigned int may_writepage:1;

    /* 能否进行unmap操作，就是将所有映射了此页的页表项清空 */
    unsigned int may_unmap:1;

    /* 是否能够进行swap交换，如果不能，在内存回收时则不扫描匿名页lru链表 */
    unsigned int may_swap:1;

    unsigned int hibernation_mode:1;

    /* 扫描结束后会标记，用于内存回收判断是否需要进行内存压缩 */
    unsigned int compaction_ready:1;

    /* 已经扫描的页框数量 */
    unsigned long nr_scanned;
    /* 已经回收的页框数量 */
    unsigned long nr_reclaimed;
};1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.

结构很简单，主要就是保存一些参数，在内存回收和内存压缩时就会根据这个结构中的这些参数，做不同的处理，后面代码会详细说明。这里我们只说说会几个特别的参数：

priority：优先级，这个参数主要会影响内存回收时一次扫描的页框数量、在shrink_lruvec()中回收到足够页框后是否继续回收、内存回收时的回写、是否取消对zone进行回收判断而直接开始回收，一共四个地方。
may_unmap：是否能够进行unmap操作，如果不能进行unmap操作，就只能对没有进程映射的页进行回收。
may_writepage：是否能够进行将页回写到磁盘的操作，这个值会影响脏的文件页与匿名页lru链表中的页的回收，如果不能进行回写操作，脏页和匿名页lru链表中的页都不能进行回收(已经回写完成的页除外，后面解释)
may_swap：能否进行swap交换，同样影响匿名页lru链表中的页的回收，如果不能进行swap交换，就不会对匿名页lru链表进行扫描，也就是在本次内存回收中，完全不会回收匿名页lru链表中的页(进程堆、栈、shmem共享内存、匿名mmap共享内存使用的页)

在快速内存回收、直接内存回收、kswapd内存回收中，这几个值的设置不一定会一致，也导致了它们对不同类型的页处理方式也不同。除了sc->may_writepage会影响页的回写外，还有进行内存分配时使用的分配标志gfp_mask中的__GFP_IO和__GFP_FS会影响页的回写，具体如下：

扫描到的非活动匿名页lru链表中的页如果还没有加入到swapcache中，需要有__GFP_IO标记才允许加入swapcache和回写。
扫描到的非活动匿名页lru链表中的页如果已经加入到了swapcache中，需要有__GFP_FS才允许进行回写。
扫描到的非活动文件页lru链表中的页需要有__GFP_FS才允许进行回写。

这里还需要说说三个重要的内核配置：

/proc/sys/vm/zone_reclaim_mode1.

这个参数只会影响快速内存回收，其值有三种：

0x1：开启zone的内存回收
0x2：开启zone的内存回收，并且允许回写
0x4：开启zone的内存回收，允许进行unmap操作

当此参数为0时，会导致快速内存回收只会对最优zone附近的几个需要进行内存回收的zone进行内存回收(说快速内存会解释)，而只要不为0，就会对zonelist中所有应该进行内存回收的zone进行内存回收。

当此参数为0x1(001)时，就如上面一行所说，允许快速内存回收对zonelist中所有应该进行内存回收的zone进行内存回收。

当此参数为0x2(010)时，在0x1的基础上，允许快速内存回收进行匿名页lru链表中的页的回写操作。

当此参数0x4(100)时，在0x1的基础上，允许快速内存回收进行页的unmap操作。

/proc/sys/vm/laptop_mode1.

此参数只会影响直接内存回收，只有两个值：

0：允许直接内存回收对匿名页lru链表中的页进行回写操作，并且允许直接内存回收唤醒flush内核线程
非0：直接内存回收不会对匿名页lru链表中的页进行回写操作

/proc/sys/vm/swapiness1.

此参数影响进行内存回收时，扫描匿名页lru链表和扫描文件页lru链表的比例，范围是0~200，系统默认是30：

接近0：进行内存回收时，更多地去扫描文件页lru链表，如果为0，那么就不会去扫描匿名页lru链表。
接近200：进行内存回收时，更多地去扫描匿名页lru链表。

三、内存回收机制的工作方式

Linux 内存回收机制主要包括后台内存回收（kswapd）、直接内存回收（direct reclaim）和 OOM 机制（Out of Memory）。这三种方式就像三道紧密协作的防线，从日常的内存维护到极端情况下的系统拯救，层层递进，保障着系统内存的稳定供应。

3.1定期扫描回收（kswapd）

定期扫描回收（kswapd）是Linux内核中的一个守护进程，用于管理系统内存和交换空间。它负责检查当前内存使用情况，并在需要时进行页面回收或交换页面到磁盘上的交换分区。

kswapd周期性地扫描系统中的页面，并根据一些策略来确定哪些页面可以被回收或者交换出去。这个过程称为页面置换（page swapping）。具体的策略可以包括LRU（Least Recently Used，最近最少使用）、LFU（Least Frequently Used，最不经常使用）等。

当系统内存紧张时，kswapd会开始工作，尝试将一些不再活跃或很少访问的页框写入交换分区。这样可以释放出物理内存供其他活跃进程使用。kswapd会根据设置的阈值和算法来调整页面置换的行为，以达到合适的内存利用率和性能。

操作系统内核线程kswapd定期进行回收内存，并通过设定三个内存阈值来衡量内存的使用情况，分别是：

页最小阈值（pages_min）
页低阈值（pages_low）
页高阈值（pages_high）

kswapd定期扫描内存的使用情况，并根据剩余内存落在这三个阈值的空间位置，进行内存的回收操作。

free < pages_min：说明进程可用内存都耗尽了,触发直接内存回收,此时只有内核才可以分配内存
pages_min<free<pages_low：说明内存压力比较大，剩余内存不多了。
       这时 kswapd会执行内存回收，直到剩余内存大于高阈值为止。
pages_low<free<pages_high：说明内存有一定压力，但还可以满足新内存请求。
free>pages_high：说明剩余内存比较多，没有内存压力。1.
2.
3.
4.
5.

3.2直接内存回收（direct reclaim）

直接内存回收就像是一场在内存紧张时突然发起的 “紧急救援” 行动，与后台内存回收的悄无声息不同，它往往伴随着进程的 “紧张时刻” 。当某个进程急切地需要申请内存资源时，如果此时系统可用内存少得可怜，连满足进程最基本的内存分配需求都无法做到，直接内存回收就会被无情地触发。这个过程就像是在战场上，当物资短缺时，不得不立即采取紧急措施来调配资源。在直接内存回收中，进程会被暂时阻塞，就像前进的道路被突然阻断，它只能无奈地等待内存回收完成，获取到足够的内存后才能继续前行。

这种回收方式是同步进行的，意味着进程的命运与内存回收紧紧绑定在一起。它虽然能够在紧急时刻迅速为进程提供所需内存，但同时也会带来一些负面影响。长时间的阻塞会让进程的执行变得迟缓，就像一个被束缚住手脚的运动员，无法正常发挥。而且，在回收内存的过程中，系统的 CPU 利用率会急剧升高，就像一台高速运转的机器，承受着巨大的压力，整个系统的负荷也会随之增大。这就好比在一个繁忙的工厂里，突然的资源调配导致生产线停滞，工人和机器都在紧张地忙碌，却无法高效地运转。所以，在系统运行过程中，我们要尽量避免直接内存回收的频繁发生，以保证系统的性能和稳定性。

3.3OOM 机制（Out of Memory）

OOM 机制（Out of Memory），即内存溢出机制，堪称 Linux 内存管理体系中的 “最后一道防线”，是在系统内存资源极度匮乏、几乎陷入绝境时才会启动的 “紧急预案” 。当直接内存回收已经竭尽全力，但系统的剩余空闲内存依然少得可怜，连最基本的内存分配请求都无法满足时，OOM Killer 机制就会被无奈地触发，就像在一场激烈的战斗中，所有常规手段都已用尽，只能祭出最后的杀手锏。

OOM Killer 机制的工作原理就像是一场残酷的 “生存竞赛” 。它会迅速扫描系统中正在运行的所有进程，如同一位严苛的评委，仔细评估每个进程的内存使用情况。在这个评估过程中，它会运用一套复杂而精妙的算法，为每个进程打分。这个分数综合考虑了进程占用的物理内存页框数量、进程的重要性以及其他一些相关因素。最终，得分最高的进程就会被无情地选中，成为这场内存危机中的 “牺牲品” 。

OOM Killer 会毫不留情地杀死这个进程，就像在资源极度短缺时，不得不牺牲一些个体来换取整体的生存。通过杀死这个占用内存较多的进程，系统成功释放出了大量的内存资源，这些资源就像注入系统的新鲜血液，使得系统能够继续艰难地运行下去。如果一次杀死进程后，内存依然不足，OOM Killer 就会像一位冷酷的执行者，继续寻找下一个得分高的进程并将其杀死，直到系统内存资源能够满足基本的运行需求。

四、回收哪些内存？

4.1Page Cache

CPU如果要访问外部磁盘上的文件，需要首先将这些文件的内容拷贝到内存中，由于硬件的限制，从磁盘到内存的数据传输速度是很慢的，如果现在物理内存有空余，干嘛不用这些空闲内存来缓存一些磁盘的文件内容呢，这部分用作缓存磁盘文件的内存就叫做page cache。

用户进程启动read()系统调用后，内核会首先查看page cache里有没有用户要读取的文件内容，如果有（cache hit），那就直接读取，没有的话（cache miss）再启动I/O操作从磁盘上读取，然后放到page cache中，下次再访问这部分内容的时候，就又可以cache hit，不用忍受磁盘的龟速了（比内存慢几个数量级）。

和CPU里的硬件cache是不是很像？两者其实都是利用的局部性原理，只不过硬件cache是CPU缓存内存的数据，而page cache是内存缓存磁盘的数据，这也体现了memory hierarchy分级的思想。

相对于磁盘，内存的容量还是很有限的，所以没必要缓存整个文件，只需要当文件的某部分内容真正被访问到时，再将这部分内容调入内存缓存起来就可以了，这种方式叫做demand paging（按需调页），把对需求的满足延迟到最后一刻，很懒很实用。

page cache中那么多的page frames，怎么管理和查找呢？这就要说到之前的文章提到的address_space结构体，一个address_space管理了一个文件在内存中缓存的所有pages。这个address_space可不是进程虚拟地址空间的address space，但是两者之间也是由很多联系的。上文讲到，mmap映射可以将文件的一部分区域映射到虚拟地址空间的一个VMA，如果有5个进程，每个进程mmap同一个文件两次（文件的两个不同部分），那么就有10个VMA，但address_space只有一个。每个进程打开一个文件的时候，都会生成一个表示这个文件的strut file，但是文件的struct inode只有一个，inode才是文件的唯一标识，指向address_space的指针就是内嵌在inode结构体中的。在page cache中，每个page都有对应的文件，这个文件就是这个page的owner，address_space将属于同一owner的pages联系起来，将这些pages的操作方法与文件所属的文件系统联系起来。

来看下address_space结构体具体是怎样构成的：

struct address_space { 
	struct inode            *host;              /* Owner, either the inode or the block_device */ 
	struct radix_tree_root  page_tree;          /* Cached pages */ 
	spinlock_t              tree_lock;          /* page_tree lock */ 
	struct prio_tree_root   i_mmap;             /* Tree of private and shared mappings */ 
	struct spinlock_t       i_mmap_lock;        /* Protects @i_mmap */       
	unsigned long           nrpages;            /* total number of pages */
        struct address_space_operations   *a_ops;   /* operations table */ 
        ...
}1.
2.
3.
4.
5.
6.
7.
8.
9.
10.

host指向address_space对应文件的inode。
address_space中的page cache之前一直是用radix tree的数据结构组织的，tree_lock是访问这个radix tree的spinlcok（现在已换成xarray）。
i_mmap是管理address_space所属文件的多个VMA映射的，用priority search tree的数据结构组织，i_mmap_lock是访问这个priority search tree的spinlcok。
nr_pages是address_space中含有的page frames的总数。
a_ops是关于page cache如何与磁盘（backing store）交互的一系列operations。

4.2从Radix Tree到XArray

radix tree的每个节点可以存放64个slots（由RADIX_TREE_MAP_SHIFT设定，小型系统为了节省内存可以配置为16），每个slot的指针指向下一层节点，最后一层slot的指针指向struct page（关于struct page请参考这篇文章），因此一个高度为2的radix tree可以容纳64个pages，高度为3则可以容纳4096个pages。

如何在radix tree中找到一个指定的page呢？那就要回顾下struct page中的mapping和index了，mapping指向page所属文件对应的address_space，进而可以找到address_space的radix tree，index既是page在文件内的offset，也可作为查找这个radix tree的索引，因为radix tree就是按page的index来组织struct page的。具体的查找方法和使用VPN做索引的page table（参考这篇文章）以及使用PPN做索引的sparse section查找（参考这篇文章）都是类似的。这里是用page index中的一部分bit位作为radix tree第一层的索引，另一部分bit位作为第二层的索引，以此类推。因为一个radix tree节点存放64个slots，因此一层索引需要6个bits，如果radix tree高度为2，则需要12个bits。

内核中具体的查找函数是find_get_page(mapping, offset)，如果在page cache中没有找到，就会触发page fault，调用__page_cache_alloc()在内存中分配若干物理页面，然后将数据从磁盘对应位置copy过来，通过add_to_page_cache()-->radix_tree_insert()放入radix tree中。在将一个page添加到page cache和从page cache移除时，需要将page和对应的radix tree都上锁。

linux中radix tree的每个slot除了存放指针，还存放着标志page和磁盘文件同步状态的tag。如果page cache中一个page在内存中被修改后没有同步到磁盘，就说这个page是dirty的，此时tag就是PAGE_CACHE_DIRTY。如果正在同步，tag就是PAGE_CACHE_WRITEBACK。只要下一层中有一个slot指向的page是dirty的，那么上一层的这个slot的tag就是PAGE_CACHE_DIRTY的，就像一滴墨水一样，放入清水后，清水也就不再完全清澈了。前面介绍struct page中的flags时提到，flags可以是PG_dirty或PG_writeback，既然struct page中已经有了标识同步状态的信息，为什么这里radix tree还要再加上tag来标记呢？这是为了管理的方便，内核可以据此快速判断某个区域中是否有dirty page或正在write back的page，而无须扫描该区域中的所有pages。

4.3Reverse Mapping

要回收一个page，可不仅仅是释放掉那么简单，别忘了linux中进程和内核都是使用虚拟地址的，多少个PTE页表项还指向这个page呢，回收之前，需要将这些PTE中P标志位设为0（not present），同时将page的物理页面号PFN也全部设成0，要不然下次PTE指向的位置存放的就是无效的数据了。可是struct page中好像并没有一个维护所有指向这个page的PTE组成的链表。

前面的文章说过，struct page数量极其庞大，如果每个page都有这样一个链表，那将显著增加内存占用，而且PTE中的内容是在不断变化的，维护这一链表的开销也是不小的。那如何找到这些PTE呢？从虚拟地址映射到物理地址是正向映射，而通过物理页面寻址映射它的虚拟地址，叫reverse mapping（逆向映射）。page的确没有直接指向PTE的反向指针，但是page所属的文件是和VMA有mmap线性映射关系的啊，通过page在文件中的offset/index，就可以知道VMA中的哪个虚拟地址映射了这个page。

在代码中的实现是这样的：

__vma_address(struct page *page, struct vm_area_struct *vma)
{
	pgoff_t pgoff = page_to_pgoff(page);
	return vma->vm_start + ((pgoff - vma->vm_pgoff) << PAGE_SHIFT);
}1.
2.
3.
4.
5.

映射了某个address_space中至少一个page的所有进程的所有VMA，就共同构成了这个address_space的priority search tree(PST)。PST是一种糅合了radix tree和heap的数据结构，其实现较为复杂，现在已经被基于augmented rbtree的interval tree所取代。

对比一下，一个进程所含有的所有VMA是通过链表和红黑树组织起来的，一个文件所对应的所有VMA是通过基于红黑树的interval tree组织起来的。因此，一个VMA被创建之后，需要通过vma_link()插入到这3种数据结构中。

五、内存回收及对系统性能的影响

5.1对zone进行一次内存回收流程

内存回收可以针对某个zone进行回收，也可以针对某个memcg进行回收，这里我们就只讨论针对某个zone进行回收的情况，无论是针对zone进行内存回收还是针对memcg进行内存回收，整个内核只有一个函数入口，就是是shrink_zone()函数，也就是内核中无论怎么样进行内存回收，最终调用到的函数都会是这个shrink_zone()，这个函数要求调用者传入一个设置好的struct scan_control结构以及目标zone的指针。

虽然是对zone进行一次内存回收，但是实际上在这个函数里，如果此zone还可以回收页框时，可能会对zone进行多次的内存回收，这是因为两个方面：

如果每次仅回收2^order个页框，满足于本次内存分配(内存分配失败时才会导致内存回收)，那么下次内存分配时又会导致内存回收，影响效率，所以，每次zone的内存回收，都是尽量回收更多页框，制定回收的目标是2^(order+1)个页框，比要求的2^order多了一倍。但是当非活动lru链表中的数量不满足这个标准时，则取消这种状态的判断。
zone的内存回收后往往伴随着zone的内存压缩，所以进行zone的内存回收时，会回收到空闲页框数量满足进行内存压缩为止。

我们看一下这个shrink_zone()：

/* 对zone进行内存回收 
 * 返回是否回收到了页框，而不是十分回收到了sc中指定数量的页框
 * 即使没回收到sc中指定数量的页框，只要回收到了页框，就返回真
 */
static bool shrink_zone(struct zone *zone, struct scan_control *sc)
{
    unsigned long nr_reclaimed, nr_scanned;
    bool reclaimable = false;

    do {
        /* 当内存回收是针对整个zone时，sc->target_mem_cgroup为NULL */
        struct mem_cgroup *root = sc->target_mem_cgroup;
        struct mem_cgroup_reclaim_cookie reclaim = {
            .zone = zone,
            .priority = sc->priority,
        };
        struct mem_cgroup *memcg;

        /* 记录本次回收开始前回收到的页框数量 
         * 第一次时是0
         */
        nr_reclaimed = sc->nr_reclaimed;
        /* 记录本次回收开始前扫描过的页框数量
         * 第一次时是0
         */
        nr_scanned = sc->nr_scanned;

        /* 获取最上层的memcg
         * 如果没有指定开始的root，则默认是root_mem_cgroup
         * root_mem_cgroup管理的每个zone的lru链表就是每个zone完整的lru链表
          */
        memcg = mem_cgroup_iter(root, NULL, &reclaim);
        do {
            struct lruvec *lruvec;
            int swappiness;

            /* 获取此memcg在此zone的lru链表 
             * 如果内核没有开启memcg，那么就是zone->lruvec
             */
            lruvec = mem_cgroup_zone_lruvec(zone, memcg);
            /* 从memcg中获取swapiness，此值代表了进行swap的频率，此值较低时，那么就更多的进行文件页的回收，此值较高时，则更多进行匿名页的回收 */
            swappiness = mem_cgroup_swappiness(memcg);

            /* 对此memcg的lru链表进行回收工作 
             * 此lru链表中的所有页都是属于此zone的
             * 每个memcg中都会为每个zone维护一个lru链表
             */
            shrink_lruvec(lruvec, swappiness, sc);

            /* 如果是对于整个zone进行回收，那么会遍历所有memcg，对所有memcg中此zone的lru链表进行回收 
             * 而如果只是针对某个memcg进行回收，如果回收到了足够内存则返回，如果没回收到足够内存，则对此memcg下面的memcg进行回收
             */
            if (!global_reclaim(sc) &&
                    sc->nr_reclaimed >= sc->nr_to_reclaim) {
                mem_cgroup_iter_break(root, memcg);
                break;
            }
            /* 下一个memcg，对于整个zone进行回收和对某个memcg进行回收但回收数量不足时会执行到此 */
            memcg = mem_cgroup_iter(root, memcg, &reclaim);
        } while (memcg);
        
        /* 计算此memcg的内存压力，保存到memcg->vmpressure */
        vmpressure(sc->gfp_mask, sc->target_mem_cgroup,
               sc->nr_scanned - nr_scanned,
               sc->nr_reclaimed - nr_reclaimed);

        if (sc->nr_reclaimed - nr_reclaimed)
            reclaimable = true;

    /* 判断是否再次此zone进行内存回收 
     * 继续对此zone进行内存回收有两种情况:
     * 1. 没有回收到比目标order值多一倍的数量页框，并且非活动lru链表中的页框数量 > 目标order多一倍的页
     * 2. 此zone不满足内存压缩的条件，则继续对此zone进行内存回收
     * 而当本次内存回收完全没有回收到页框时则返回，这里大概意思就是想回收比order更多的页框
     */
    } while (should_continue_reclaim(zone, sc->nr_reclaimed - nr_reclaimed,
                     sc->nr_scanned - nr_scanned, sc));

    return reclaimable;
}1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
51.
52.
53.
54.
55.
56.
57.
58.
59.
60.
61.
62.
63.
64.
65.
66.
67.
68.
69.
70.
71.
72.
73.
74.
75.
76.
77.
78.
79.
80.

在此函数中，首先会遍历memcg，根据memcg获取lru链表描述符lruvec与swapiness，这个swapiness的值的范围是0~200，它会影响扫描匿名页lru链表和文件页lru链表的页框数量，当此值越低时，就需要扫描的匿名页lru链表的页框越少，当此值为0时，则不扫描匿名页lru链表的页框，相反，此值越高，则需要扫描的匿名页lru链表的页框越多，当其为200时，则只扫描匿名页lru链表中的页框，不扫描文件页lru链表中的页框。然后调用shrink_lruvec()对此lru链表描述符的lru链表进行扫描，最后遍历完所有memcg后，判断是否继续对此zone进行内存回收，总的来说，流程如下：

从root_memcg开始遍历memcg
获取memcg的lru链表描述符lruvec
获取memcg的swapiness
调用shrink_lruvec()对此memcg的lru链表进行处理

遍历完所有memcg后，检查是否还要对此zone再次进行内存回收，核心函数就是shrink_lruvec()，我们先看代码：

/* 对lru链表描述符lruvec中的lru链表进行内存回收，此lruvec有可能属于一个memcg，也可能是属于一个zone 
 * lruvec: lru链表描述符，里面有5个lru链表，活动/非活动匿名页lru链表，活动/非活动文件页lru链表，禁止换出页链表
 * swappiness: 扫描匿名页的亲和力，其值越低，就扫描越少的匿名页，当为0时，基本不会扫描匿名页lru链表，除非针对整个zone进行内存回收时，此zone的所有文件页都释放了都不能达到高阀值，那就只对匿名页进行扫描
 * sc: 扫描控制结构
 */
static void shrink_lruvec(struct lruvec *lruvec, int swappiness,
              struct scan_control *sc)
{
    unsigned long nr[NR_LRU_LISTS];
    unsigned long targets[NR_LRU_LISTS];
    unsigned long nr_to_scan;
    enum lru_list lru;
    unsigned long nr_reclaimed = 0;
    /* 需要回收的页框数量 */
    unsigned long nr_to_reclaim = sc->nr_to_reclaim;
    struct blk_plug plug;
    bool scan_adjusted;

    /* 对这个lru链表描述符中的每个lru链表，计算它们本次扫描应该扫描的页框数量 
     * 计算好的每个lru链表需要扫描的页框数量保存在nr中
     * 每个lru链表需要扫描多少与sc->priority有关，sc->priority越小，那么扫描得越多
     */
    get_scan_count(lruvec, swappiness, sc, nr);

    /* 将nr的数据复制到targets中 */
    memcpy(targets, nr, sizeof(nr));

    /* 是否将nr[]中的数量页数都扫描完才停止
     * 如果是针对整个zone进行扫描，并且不是在kswapd内核线程中调用的，优先级为默认优先级，就会无视需要回收的页框数量，只有将nr[]中的数量页数都扫描完才停止
     * 快速回收不会这样做(快速回收的优先级不是DEF_PRIORITY)
     */
    scan_adjusted = (global_reclaim(sc) && !current_is_kswapd() &&
             sc->priority == DEF_PRIORITY);

    /* 初始化这个struct blk_plug
     * 主要初始化list，mq_list，cb_list这三个链表头
     * 然后current->plug = plug
     */
    blk_start_plug(&plug);
    /* 如果LRU_INACTIVE_ANON，LRU_ACTIVE_FILE，LRU_INACTIVE_FILE这三个其中一个需要扫描的页框数没有扫描完，那扫描就会继续 
     * 注意这里不会判断LRU_ACTIVE_ANON需要扫描的页框数是否扫描完，这里原因大概是因为系统不太希望对匿名页lru链表中的页回收
     */
    while (nr[LRU_INACTIVE_ANON] || nr[LRU_ACTIVE_FILE] ||
                    nr[LRU_INACTIVE_FILE]) {
        unsigned long nr_anon, nr_file, percentage;
        unsigned long nr_scanned;

        /* 以LRU_INACTIVE_ANON，LRU_INACTIVE_ANON，LRU_INACTIVE_FILE，LRU_ACTIVE_FILE这个顺序遍历lru链表 
         * 然后对遍历到的lru链表进行扫描，一次最多32个页框
         */
        for_each_evictable_lru(lru) {
            /* nr[lru类型]如果有页框需要扫描 */
            if (nr[lru]) {
                /* 获取本次需要扫描的页框数量，nr[lru]与SWAP_CLUSTER_MAX的最小值 
                 * 也就是每一轮最多只扫描SWAP_CLUSTER_MAX(32)个页框
                 */
                nr_to_scan = min(nr[lru], SWAP_CLUSTER_MAX);
                /* nr[lru类型]减掉本次需要扫描的页框数量 */
                nr[lru] -= nr_to_scan;

                /* 对此lru类型的lru链表进行内存回收 
                 * 一次扫描的页框数是nr[lru]与SWAP_CLUSTER_MAX的最小值，也就是如果全部能回收，一次也就只能回收SWAP_CLUSTER_MAX(32)个页框
                 * 都是从lru链表末尾向前扫描
                 * 本次回收的页框数保存在nr_reclaimed中
                 */
                nr_reclaimed += shrink_list(lru, nr_to_scan,
                                lruvec, sc);
            }
        }

        /* 没有回收到足够页框，或者需要忽略需要回收的页框数量，尽可能多的回收页框，则继续进行回收
         * 当scan_adjusted为真时，扫描到nr[三个类型]数组中的数都为0为止，会忽略是否回收到足够页框，即使回收到足够页框也继续进行扫描
         * 也就是尽可能的回收页框，越多越好，alloc_pages()会是这种情况
         */
        if (nr_reclaimed < nr_to_reclaim || scan_adjusted)
            continue;

        /* kswapd和针对某个memcg进行回收的情况中会调用到此，已经回收到了足够数量的页框，调用到此是用于判断是否还要继续扫描，因为已经回收到了足够页框了 */
        /* 扫描一遍后，剩余需要扫描的文件页数量和匿名页数量 */
        nr_file = nr[LRU_INACTIVE_FILE] + nr[LRU_ACTIVE_FILE];
        nr_anon = nr[LRU_INACTIVE_ANON] + nr[LRU_ACTIVE_ANON];

        /* 已经扫描完成了，退出循环 */
        if (!nr_file || !nr_anon)
            break;

        /* 下面就是计算再扫描多少页框，会对nr[]中的数进行相应的减少 
         * 调用到这里肯定是kswapd进程或者针对memcg的页框回收，并且已经回收到了足够的页框了
         * 如果nr[]中还剩余很多数量的页框没有扫描，这里就通过计算，减少一些nr[]待扫描的数量
         * 设置scan_adjusted，之后把nr[]中剩余的数量扫描完成
         */
        if (nr_file > nr_anon) {
            /* 剩余需要扫描的文件页多于剩余需要扫描的匿名页时 */

            /* 原始的需要扫描匿名页数量 */
            unsigned long scan_target = targets[LRU_INACTIVE_ANON] +
                        targets[LRU_ACTIVE_ANON] + 1;
            lru = LRU_BASE;
            /* 计算剩余的需要扫描的匿名页数量占 */
            percentage = nr_anon * 100 / scan_target;
        } else {
            /* 剩余需要扫描的文件页少于剩余需要扫描的匿名页时 */
            unsigned long scan_target = targets[LRU_INACTIVE_FILE] +
                        targets[LRU_ACTIVE_FILE] + 1;
            lru = LRU_FILE;
            percentage = nr_file * 100 / scan_target;
        }

        nr[lru] = 0;
        nr[lru + LRU_ACTIVE] = 0;

        lru = (lru == LRU_FILE) ? LRU_BASE : LRU_FILE;
        nr_scanned = targets[lru] - nr[lru];
        nr[lru] = targets[lru] * (100 - percentage) / 100;
        nr[lru] -= min(nr[lru], nr_scanned);

        lru += LRU_ACTIVE;
        nr_scanned = targets[lru] - nr[lru];
        nr[lru] = targets[lru] * (100 - percentage) / 100;
        nr[lru] -= min(nr[lru], nr_scanned);

        scan_adjusted = true;
    }
    blk_finish_plug(&plug);
    /* 总共回收的页框数量 */
    sc->nr_reclaimed += nr_reclaimed;

    /* 非活动匿名页lru链表中页数量太少 */
    if (inactive_anon_is_low(lruvec))
        /* 从活动匿名页lru链表中移动一些页去非活动匿名页lru链表，最多32个 */
        shrink_active_list(SWAP_CLUSTER_MAX, lruvec,
                   sc, LRU_ACTIVE_ANON);

    /* 如果太多脏页进行回写了，这里就睡眠100ms */
    throttle_vm_writeout(sc->gfp_mask);
}1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
51.
52.
53.
54.
55.
56.
57.
58.
59.
60.
61.
62.
63.
64.
65.
66.
67.
68.
69.
70.
71.
72.
73.
74.
75.
76.
77.
78.
79.
80.
81.
82.
83.
84.
85.
86.
87.
88.
89.
90.
91.
92.
93.
94.
95.
96.
97.
98.
99.
100.
101.
102.
103.
104.
105.
106.
107.
108.
109.
110.
111.
112.
113.
114.
115.
116.
117.
118.
119.
120.
121.
122.
123.
124.
125.
126.
127.
128.
129.
130.
131.
132.
133.
134.
135.
136.

此函数主要是对lru链表描述符中的lru链表进行处理，我们知道，lru链表描述符中一共有5个链表：LRU_ACTIVE_ANON，LRU_INACTIVE_ANON，LRU_ACTIVE_FILE，LRU_INACTIVE_FILE，LRU_UNEVICTABLE。对于内存回收来说，它只会处理前面4个lru链表，也就是活动匿名页lru链表，非活动匿名页lru链表，活动文件页lru链表，非活动文件页lru链表。此函数主要工作就是：

1.调用get_scan_count()计算每个lru链表需要扫描的页框数量，保存到nr数组中；
2.循环判断nr数组中是否还有lru链表没有扫描完成

以活动匿名页lru链表、非活动匿名页lru链表、活动文件页lru链表、非活动文件页lru链表的顺序作为一轮扫描，每次每个lru链表扫描32个页框，并且在nr数组中减去lru链表对应扫描的数量；
一轮扫描结束后判断是否回收到了足够页框，没有回收到足够页框则跳到 2 继续循环判断nr数组；
已经回收到了足够页框，当nr数组有剩余时，判断是否要对lru链表继续扫描，如果要继续扫描，则跳到 21.
2.
3.

3.如果非活动匿名页lru链表中页数量太少，则对活动匿名页进行一个32个页框的扫描；
4.如果太多脏页正在进行回写，则睡眠100ms

这里需要说明的有两点：计算每个lru链表需要扫描的数量和调整nr数组，在get_scan_count()函数中会计算每个lru链表需要扫描的页框数量，然后将它们保存到nr数组中，在此，有两个因素会影响这4个lru链表需要扫描的数量，一个是sc->priority(扫描优先级)，一个是swapiness。

sc->priority：影响的是这4个lru链表扫描页框数量的基准值，当sc->priority越小，每个lru链表需要扫描的页框数量就越多，当sc->priority为0时，则本次shrink_lruvec()会对每个lru链表都完全扫描一遍。在不同内存回收过程中，使用的sc->priority不同，而sc->priority默认值为12。
swapiness：影响的是在基准值的基础上，是否做调整，让系统更多地去扫描文件页lru链表，或者更多地去扫描匿名页lru链表。当swapiness为100时，扫描文件页lru链表与扫描匿名页lru链表是平衡的，并不倾向与谁，也就是它们需要扫描的页框就是就是sc->priority决定的基准值，当swapiness为0,时，就不会去扫描匿名页lru链表，只扫描文件页lru链表。

有兴趣的可以去看看get_scan_count()函数，这个函数这里就不详细进行说明了，之后可能会出篇文章对此函数进行详细说明。

计算好每个lru链表需要扫描的页框数量后，就以活动匿名页lru链表、非活动匿名页lru链表、活动文件页lru链表、非活动文件页lru链表的顺序对每个链表进行一次最多32个页框的扫描，然后将对应的nr数组的数值进行减少，当对这4个lru链表都进行过一次扫描后，判断是否回收到了足够页框，如果没有回收到足够页框，则继续扫描，而如果已经回收到了足够页框的话，并且nr数组中的数还有剩余的情况下，这里会有两种可能，一种是直接返回，另一种是继续扫描，这两种情况发生的条件如下：

回收到足够页框后直接返回：快速内存回收、kswapd内存回收中会这样做，在回收到sc->nr_to_reclaim数量的页框后直接返回上一级
回收到足够页框后继续扫描：直接内存回收时第一次调用shrink_zone()时、kswapd针对某个memcg进行内存回收时会这样做，即使回收到sc->nr_to_reclaim数量的页框后，还会继续扫描，直到nr数组为0具体见后面直接内存回收

当回收到sc>nr_to_reclaim数量的页框后，还打算继续扫描的情况，则会继续扫描这4个lru链表，而对于kswapd针对某个memcg进行内存回收的情况会稍微有所不同，虽然这种情况也会继续扫描，但是它会执行一些代码去减少一些nr数组中的值，这样重新扫描时，就会扫描得少一些。

接下来说说对每个lru链表的处理，在shrink_lruvec()中已经设计出了每个lru链表一次扫描32个页框，然后调用shrink_list()函数，我们先看看shrink_list():

/*
 * 对lru链表进行处理
 * lru: lru链表的类型
 * nr_to_scan: 需要扫描的页框数量，此值 <= 32，当链表长度不足32时，就为链表长度
 * lruvec: lru链表描述符，与lru参数结合就得出待处理的lru链表
 * sc: 扫描控制结构
 */
static unsigned long shrink_list(enum lru_list lru, unsigned long nr_to_scan,
                 struct lruvec *lruvec, struct scan_control *sc)
{
    /* 如果lru类型是活动lru(包括活动匿名页lru和活动文件页lru) */
    if (is_active_lru(lru)) {
        /* 如果此活动lru对应的非活动lru链表中维护的页框数量太少，则会从活动lru链表中移动一些到对应非活动lru链表中 
         * 这里需要注意，文件页和匿名页的非活动lru链表中是否少计算方式是不同的
         * 匿名页的话，有一个经验值表示大概多少匿名页保存到非活动匿名页lru链表
         * 文件页的话，大概非活动文件页数量要大于活动文件页
         * 而如果遇到page->_count == 0的页，则会将它们释放到每CPU页框高速缓存中
         */
        if (inactive_list_is_low(lruvec, lru))
            /* 从活动lru中移动一些页框到非活动lru中，移动nr_to_scan个，nr_to_scan <= 32，从活动lru链表末尾拿出页框移动到非活动lru链表头 
             * 只有代码段的页最近被访问了，会将其加入到活动lru链表头部，其他页即使最近被访问了，也移动到非活动lru链表
             */
            shrink_active_list(nr_to_scan, lruvec, sc, lru);
        return 0;
    }

    /* 如果lru类似是非活动lru，那么会对此lru类型的lru链表中的页框进行回收 */
    return shrink_inactive_list(nr_to_scan, lruvec, sc, lru);
}1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.

可以很明显看到，只有非活动lru链表中页框数量不足时，才会调用shrink_active_list()对活动lru链表进行处理，否则并不会进行处理，不过需要注意，即使并不对活动lru链表进行处理，在shrink_lruvec()中也会相应减少nr数组中的数值。而怎么判断非活动lru链表保存的页框数量过少的。需要注意，此函数调用成功后，返回值 >= 0。大于0说明回收到了页框，因为内存回收只会对非活动lru链表中的页进行回收，所以只有对非活动lru链表进行处理时返回值才会大于0。

5.2对活动lru链表处理

我们先看怎么对活动lru链表进行处理的，活动lru链表包括活动匿名页lru链表以及活动文件页lru链表，这两个lru链表都会调用shrink_active_list()进行处理：

/*
 * 从lruvec中的lru类型的链表中获取一些页，并移动到非活动lru链表头部，注意此函数会以lru参数为类型，比如lru参数为LRU_ACTIVE_ANON，那只会处理ANON类型的页，不会处理FILE类型的页
 * 只有代码段的页最近被访问了，会将其加入到活动lru链表头部，其他页即使最近被访问了，也移动到非活动lru链表
 * 从lruvec中的lru类型的链表中拿出一些页之后，会判断这些页的去处，然后将page->_count = 1的页进行释放，因为说明此页只有隔离的时候对其page->_count进行了++，已经没有进程或模块引用此页
 * 将其释放到伙伴系统的每CPU高速缓存中
 * nr_to_scan: 默认是32，扫描次数，如果扫描的全是普通页，那最多扫描32个页，如果全是大页，最多扫描(大页/普通页)*32个页
 * lruvec: 需要扫描的lru链表(里面包括一个zone中所有类型的lru链表)
 * sc: 扫描控制结构
 * lru: 需要扫描的类型，是active_file或者active_anon的lru链表
 */
static void shrink_active_list(unsigned long nr_to_scan,
                   struct lruvec *lruvec,
                   struct scan_control *sc,
                   enum lru_list lru)
{
    unsigned long nr_taken;
    unsigned long nr_scanned;
    unsigned long vm_flags;
    /* 从lru中获取到的页存放在这，到最后这里面还有剩余的页的话，就把它们释放回伙伴系统 */
    LIST_HEAD(l_hold);    /* The pages which were snipped off */
    /* 移动到活动lru链表头部的页的链表 */
    LIST_HEAD(l_active);
    /* 将要移动到非活动lru链表的页放在这 */
    LIST_HEAD(l_inactive);
    struct page *page;
    /* lruvec的统计结构 */
    struct zone_reclaim_stat *reclaim_stat = &lruvec->reclaim_stat;
    unsigned long nr_rotated = 0;
    isolate_mode_t isolate_mode = 0;
    /* lru是否属于LRU_INACTIVE_FILE或者LRU_ACTIVE_FILE */
    int file = is_file_lru(lru);
    /* lruvec所属的zone */
    struct zone *zone = lruvec_zone(lruvec);

    /* 将当前CPU的多个pagevec中的页都放入lru链表中 */
    lru_add_drain();

    /* 从kswapd调用过来的情况下，sc->may_unmap为1
     * 直接内存回收的情况，sc->may_unmap为1
     * 快速内存回收的情况，sc->may_unmap与zone_reclaim_mode有关
     */
    if (!sc->may_unmap)
        isolate_mode |= ISOLATE_UNMAPPED;

    /* 从kswapd调用过来的情况下，sc->may_writepage与latptop_mode有关
     * 直接内存回收的情况，sc->may_writepage与latptop_mode有关
     * 快速内存回收的情况，sc->may_writepage与zone_reclaim_mode有关
     */
    if (!sc->may_writepage)
        isolate_mode |= ISOLATE_CLEAN;

    /* 对zone的lru_lock上锁 */
    spin_lock_irq(&zone->lru_lock);

    /* 从lruvec中lru类型链表的尾部拿出一些页隔离出来，放入到l_hold中，lru类型一般是LRU_ACTIVE_ANON或LRU_ACTIVE_FILE
     * 也就是从活动的lru链表中隔离出一些页，从活动lru链表的尾部依次拿出
     * 当sc->may_unmap为0时，则不会将有进程映射的页隔离出来
     * 当sc->may_writepage为0时，则不会将脏页和正在回写的页隔离出来
     * 隔离出来的页会page->_count++
     * nr_taken保存拿出的页的数量
     */
    nr_taken = isolate_lru_pages(nr_to_scan, lruvec, &l_hold,
                     &nr_scanned, sc, isolate_mode, lru);
    if (global_reclaim(sc))
        __mod_zone_page_state(zone, NR_PAGES_SCANNED, nr_scanned);

    reclaim_stat->recent_scanned[file] += nr_taken;

    /* 做统计 */
    __count_zone_vm_events(PGREFILL, zone, nr_scanned);
    __mod_zone_page_state(zone, NR_LRU_BASE + lru, -nr_taken);
    __mod_zone_page_state(zone, NR_ISOLATED_ANON + file, nr_taken);
    /* 释放lru链表锁 */
    spin_unlock_irq(&zone->lru_lock);

    /* 将l_hold中的页一个一个处理 */
    while (!list_empty(&l_hold)) {
        /* 是否需要调度，需要则调度 */
        cond_resched();
        /* 将页从l_hold中拿出来 */
        page = lru_to_page(&l_hold);
        list_del(&page->lru);

        /* 如果页是unevictable(不可回收)的，则放回到LRU_UNEVICTABLE这个lru链表中，这个lru链表中的页不能被交换出去 */
        if (unlikely(!page_evictable(page))) {
            /* 放回到page所应该属于的lru链表中 
             * 而这里实际上是将页放到zone的LRU_UNEVICTABLE链表中
             */
            putback_lru_page(page);
            continue;
        }

        /* buffer_heads的数量超过了结点允许的最大值的情况 */
        if (unlikely(buffer_heads_over_limit)) {
            /* 文件页才有的page才有PAGE_FLAGS_PRIVATE标志 */
            if (page_has_private(page) && trylock_page(page)) {
                if (page_has_private(page))
                    /* 释放此文件页所拥有的buffer_head链表中的buffer_head，并且page->_count-- */
                    try_to_release_page(page, 0);
                unlock_page(page);
            }
        }

        /* 检查此页面最近是否有被访问过，通过映射了此页的页表项的Accessed进行检查，并且会清除页表项的Accessed标志
         * 如果此页最近被访问过，返回的是Accessed为1的数量页表项数量
         */
        if (page_referenced(page, 0, sc->target_mem_cgroup,
                    &vm_flags)) {
            /* 如果是大页，则记录一共多少个页，如果是普通页，则是1 */
            nr_rotated += hpage_nr_pages(page);

            /* 如果此页映射的是代码段，则将其放到l_active链表中，此链表之后会把页放入页对应的活动lru链表中
             * 可以看出对于代码段的页，还是比较倾向于将它们放到活动文件页lru链表的
             * 当代码段没被访问过时，也是有可能换到非活动文件页lru链表的
             */
            if ((vm_flags & VM_EXEC) && page_is_file_cache(page)) {
                list_add(&page->lru, &l_active);
                continue;
            }
        }
        /* 将页放到l_inactive链表中
         * 只有最近访问过的代码段的页不会被放入，其他即使被访问过了，也会被放入l_inactive
         */
        ClearPageActive(page);    /* we are de-activating */
        list_add(&page->lru, &l_inactive);
    }

    spin_lock_irq(&zone->lru_lock);

    /* 记录的是最近被加入到活动lru链表的页数量，之后这些页被返回到active链表 */
    reclaim_stat->recent_rotated[file] += nr_rotated;

    /* 将l_active链表中的页移动到lruvec->lists[lru]中，这里是将active的页移动到active的lru链表头部 */
    move_active_pages_to_lru(lruvec, &l_active, &l_hold, lru);
    /* 将l_inactive链表中的页移动到lruvec->lists[lru - LRU_ACITVE]中，这里是将active的页移动到inactive的lru头部 */
    move_active_pages_to_lru(lruvec, &l_inactive, &l_hold, lru - LRU_ACTIVE);
    __mod_zone_page_state(zone, NR_ISOLATED_ANON + file, -nr_taken);
    spin_unlock_irq(&zone->lru_lock);

    mem_cgroup_uncharge_list(&l_hold);
    /* 剩下的页的处理，剩下的都是page->_count为0的页，作为冷页放回到伙伴系统的每CPU单页框高速缓存中 */
    free_hot_cold_page_list(&l_hold, true);
}1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
51.
52.
53.
54.
55.
56.
57.
58.
59.
60.
61.
62.
63.
64.
65.
66.
67.
68.
69.
70.
71.
72.
73.
74.
75.
76.
77.
78.
79.
80.
81.
82.
83.
84.
85.
86.
87.
88.
89.
90.
91.
92.
93.
94.
95.
96.
97.
98.
99.
100.
101.
102.
103.
104.
105.
106.
107.
108.
109.
110.
111.
112.
113.
114.
115.
116.
117.
118.
119.
120.
121.
122.
123.
124.
125.
126.
127.
128.
129.
130.
131.
132.
133.
134.
135.
136.
137.
138.
139.
140.
141.
142.
143.

这里面，首先，会将当前CPU所有的lru缓存中的页全部放到lru链表中，其次调用isolate_lru_pages()从lru链表的末尾隔离出一些页来放入到l_hold链表中，成功隔离出来的页的page->_count会进行++。这个函数在内存回收中是一个通用函数，也就是它即可以用来隔离活动lru链表的页，也可以用来隔离非活动lru链表的页，需要注意这个函数依赖于sc->may_writepage和sc->may_unmap，这两个变量在之前有过说明，也如注释上所说，当sc->may_writepage为0时，则不会将正在回写的页和脏页隔离出来，当sc->may_unmap为0时，则不会将有进程映射的页隔离出来，这些页都会被跳过，这样一来，在这些情况下，实际隔离的页就会少于需要扫描的页。隔离出一些页后，又会调用page_referenced()函数，此函数通过反向映射，检查映射了此页的进程页表项有多少个的Accessed被置1了，然后清除这些页表项的Accessed标志，此标志被置1说明这些进程最近访问过此页。

当最近有进程访问过此页，如果此页是映射了代码段的页，就把此页加入到l_active链表，其他页则清除PG_active标志，通过page->lru这个链表结点加入到l_inactive链表。也就是隔离出来的页，只有代码段最近被访问过了，才会留在活动lru链表中，其余的页，都必须要通过page->lru这个链表结点移动到非活动lru链表头中。不过因为代码段的页是属于文件页lru链表，也就是对于活动匿名页lru链表中隔离出来的页，所有都放到非活动匿名页lru链表头部，而对于活动文件页lru链表中隔离出来的页，除了最近被访问过的代码段的页，其余页都移动到非活动文件页lru链表头部。

之后调用move_active_pages_to_lru()函数，将l_active中的页加入到活动lru链表头部，将l_inactive中的页加入到非活动lru链表尾部，并且会对成功加入的页的page->_count进行--，这样与成功隔离时正好进行了一加一减的操作。在将活动页移动到非活动lru链表时，可能会扫描到一种页，它们的page->_count为0，也就是已经没有任何模块和进程对其进行引用了，这种页就可以直接释放了。所以看到shrink_active_list()函数最后将这些类型的页进行释放。关于isolate_lru_pages()、page_referenced()和move_active_pages_to_lru()函数，以后的文章再分析，这篇文章放不下了。

shrink_active_list()调用完成后，所有隔离出来的页都已经被放入到相应的lru链表中了。注意，这里在移动页框时并不会使用lru缓存，之前关于lru链表分析的文章也说过，在内存回收过程中，只有将页加入到LRU_UNEVICTABLE链表中时需要用到lru缓存，而对于页在相同类型的lru链表间移动时，是不会使用到lru缓存的。shrink_active_list()函数总结要点有五：

将本cpu的lru缓存全部清空，将lru缓存的页放到lru链表中，而其他CPU的则不处理
根据sc->may_writepage与sc->may_unmap选择要隔离的页
如果结点buffer_heads数量超过限制值，则会尝试对扫描到的文件页进行buffer_heads的释放，进行释放后的文件页的page->_count--
将所有映射了隔离页的页表项Accessed都跟清0
将最近被访问过的代码段的页移动到活动lru链表头，其余页都移动到非活动lru链表头
将page->_count == 0的页进行释放。

5.3对非活动lru链表进行处理

接下来我们看看对于非活动lru链表的分析，非活动lru链表包括非活动匿名页lru链表和非活动文件页lru链表，它们都会调用shrink_inactive_list()，此函数就要比活动lru链表的处理函数shrink_active_list()复杂得多，如下：

/* 对lruvec这个lru链表描述符中的lru类型的lru链表进行内存回收，这个lru类型一定是LRU_INACTIVE_ANON或者LRU_INACTIVE_FILE类型
 * nr_to_scan: 最多扫描多少个页框
 * lruvec: lru链表描述符，里面有5个lru链表
 * sc: 扫描控制结构
 * lru: 需要扫描的lru链表
 * 返回本次回收的页框数量
 */
static noinline_for_stack unsigned long
shrink_inactive_list(unsigned long nr_to_scan, struct lruvec *lruvec,
             struct scan_control *sc, enum lru_list lru)
{
    LIST_HEAD(page_list);
    unsigned long nr_scanned;
    unsigned long nr_reclaimed = 0;
    unsigned long nr_taken;
    unsigned long nr_dirty = 0;
    unsigned long nr_congested = 0;
    unsigned long nr_unqueued_dirty = 0;
    unsigned long nr_writeback = 0;
    unsigned long nr_immediate = 0;
    isolate_mode_t isolate_mode = 0;
    /* 此非活动lru是否为非活动文件页lru */
    int file = is_file_lru(lru);
    /* lru所属的zone */
    struct zone *zone = lruvec_zone(lruvec);
    struct zone_reclaim_stat *reclaim_stat = &lruvec->reclaim_stat;

    /* 如果隔离的页数量多于非活动的页数量，则是隔离太多页了，个人猜测这里是控制并发
     * 当zone的NR_INACTIVE_FILE/ANON < NR_ISOLATED_ANON时，有一种情况是其他CPU也在对此zone进行内存回收，所以NR_ISOLATED_ANON比较高
     */
    while (unlikely(too_many_isolated(zone, file, sc))) {
        /* 这里会休眠等待100ms，如果是并发进行内存回收，另一个CPU可能也在执行内存回收 */
        congestion_wait(BLK_RW_ASYNC, HZ/10);

        /* We are about to die and free our memory. Return now. */
        /* 当前进程被其他进程kill了，这里接受到了kill信号 */
        if (fatal_signal_pending(current))
            return SWAP_CLUSTER_MAX;
    }

    /* 将当前cpu的pagevec中的页放入到lru链表中 
     * 而其他CPU的pagevec中的页则不会放回到lru链表中
     * 这样做似乎是因为效率问题
     */
    lru_add_drain();

    if (!sc->may_unmap)
        isolate_mode |= ISOLATE_UNMAPPED;
    if (!sc->may_writepage)
        isolate_mode |= ISOLATE_CLEAN;

    /* 对lru链表上锁 */
    spin_lock_irq(&zone->lru_lock);

    /* 从lruvec这个lru链表描述符的lru类型的lru链表中隔离最多nr_to_scan个页出来，隔离时是从lru链表尾部开始拿，然后放到page_list 
     * 返回隔离了多少个此非活动lru链表的页框
     */
    nr_taken = isolate_lru_pages(nr_to_scan, lruvec, &page_list,
                     &nr_scanned, sc, isolate_mode, lru);

    /* 更新zone中对应lru中页的数量 */
    __mod_zone_page_state(zone, NR_LRU_BASE + lru, -nr_taken);
    /* 此zone对应隔离的ANON/FILE页框数量 */
    __mod_zone_page_state(zone, NR_ISOLATED_ANON + file, nr_taken);

    /* 如果是针对整个zone的内存回收，而不是某个memcg的内存回收的情况 */
    if (global_reclaim(sc)) {
        /* 统计zone中扫描的页框总数 */
        __mod_zone_page_state(zone, NR_PAGES_SCANNED, nr_scanned);
        /* 如果是在kswapd内核线程中调用到此的，则扫描的页框数量统计到zone的PGSCAN_KSWAPD */
        if (current_is_kswapd())
            __count_zone_vm_events(PGSCAN_KSWAPD, zone, nr_scanned);
        else
            /* 否则扫描的数量统计到zone的PGSCAN_DIRECT */
            __count_zone_vm_events(PGSCAN_DIRECT, zone, nr_scanned);
    }
    /* 释放lru锁 */
    spin_unlock_irq(&zone->lru_lock);

    /* 隔离出来的页数量为0 */
    if (nr_taken == 0)
        return 0;

    /* 上面的代码已经将非活动lru链表中的一些页拿出来放到page_list中了，这里是对page_list中的页进行内存回收 
     * 此函数的步骤:
     * 1.此页是否在进行回写(两种情况会导致回写，之前进行内存回收时导致此页进行了回写；此页为脏页，系统自动将其回写)，这种情况同步回收和异步回收有不同的处理
     * 2.此次回收时非强制进行回收，那要先判断此页能不能进行回收
     *         如果是匿名页，只要最近此页被进程访问过，则将此页移动到活动lru链表头部，否则回收
     *         如果是映射可执行文件的文件页，只要最近被进程访问过，就放到活动lru链表，否则回收
     *         如果是其他的文件页，如果最近被多个进程访问过，移动到活动lru链表，如果只被1个进程访问过，但是PG_referenced置位了，也放入活动lru链表，其他情况回收
     * 3.如果遍历到的page为匿名页，但是又不处于swapcache中，这里会尝试将其加入到swapcache中并把页标记为脏页，这个swapcache作为swap缓冲区，是一个address_space
     * 4.对所有映射了此页的进程的页表进行此页的unmap操作
     * 5.如果页为脏页，则进行回写，分同步和异步，同步情况是回写完成才返回，异步情况是加入块层的写入队列，标记页的PG_writeback表示正在回写就返回，此页将会被放到非活动lru链表头部
     * 6.检查页的PG_writeback标志，如果此标志位0，则说明此页的回写完成(两种情况: 1.同步回收 2.之前异步回收对此页进行的回写已完成)，则从此页对应的address_space中的基树移除此页的结点，加入到free_pages链表
     *        对于PG_writeback标志位1的，将其重新加入到page_list链表，这个链表之后会将里面的页放回到非活动lru链表末尾，下次进行回收时，如果页回写完成了就会被释放
     * 7.对free_pages链表的页释放
     *
     * page_list中返回时有可能还有页，这些页是要放到非活动lru链表末尾的页，而这些页当中，有些页是正在进行回收的回写，当这些回写完成后，系统再次进行内存回收时，这些页就会被释放
     *        而有一些页是不满足回收情况的页
     * nr_dirty: page_list中脏页的数量
     * nr_unqueued_dirty: page_list中脏页但并没有正在回写的页的数量
     * nr_congested: page_list中正在进行回写并且设备正忙的页的数量(这些页可能回写很慢)
     * nr_writeback: page_list中正在进行回写但不是在回收的页框数量
     * nr_immediate: page_list中正在进行回写的回收页框数量
     * 返回本次回收的页框数量
     */
    nr_reclaimed = shrink_page_list(&page_list, zone, sc, TTU_UNMAP,
                &nr_dirty, &nr_unqueued_dirty, &nr_congested,
                &nr_writeback, &nr_immediate,
                false);

    /* 对lru上锁 */
    spin_lock_irq(&zone->lru_lock);

    /* 更新reclaim_stat中的recent_scanned */
    reclaim_stat->recent_scanned[file] += nr_taken;

    /* 如果是针对整个zone，而不是某个memcg的情况 */
    if (global_reclaim(sc)) {
        /* 如果是在kswakpd内核线程中 */
        if (current_is_kswapd())
            /* 更新到zone的PGSTEAL_KSWAPD */
            __count_zone_vm_events(PGSTEAL_KSWAPD, zone,
                           nr_reclaimed);
        else
            /* 不是在kswapd内核线程中，更新到PGSTEAL_DIRECT */
            __count_zone_vm_events(PGSTEAL_DIRECT, zone,
                           nr_reclaimed);
    }

    /* 
     * 将page_list中剩余的页放回它对应的lru链表中，这里的页有三种情况:
     * 1.最近被访问了，放到活动lru链表头部
     * 2.此页需要锁在内存中，加入到unevictablelru链表
     * 3.此页为非活动页，移动到非活动lru链表头部
     * 当页正在进行回写回收，当回写完成后，通过判断页的PG_reclaim可知此页正在回收，会把页移动到非活动lru链表末尾，具体见end_page_writeback()函数
     * 加入lru的页page->_count--
     * 因为隔离出来时page->_count++，而在lru中是不需要对page->_count++的
     */
    putback_inactive_pages(lruvec, &page_list);

    /* 更新此zone对应隔离的ANON/FILE页框数量，这里减掉了nr_taken，与此函数之前相对应 */
    __mod_zone_page_state(zone, NR_ISOLATED_ANON + file, -nr_taken);

    spin_unlock_irq(&zone->lru_lock);

    mem_cgroup_uncharge_list(&page_list);
    /* 释放page_list中剩余的页到伙伴系统中的每CPU页高速缓存中，以冷页处理 
     * 这里剩余的就是page->_count == 0的页
     */
    free_hot_cold_page_list(&page_list, true);

    /* 隔离出来的页都在进行回写(但不是回收造成的回写) */
    if (nr_writeback && nr_writeback == nr_taken)
        /* 标记ZONE的ZONE_WRITEBACK，标记此zone许多页在回写 */
        set_bit(ZONE_WRITEBACK, &zone->flags);

    /* 本次内存回收是针对整个zone的，这里面主要对zone的flags做一些标记 */
    if (global_reclaim(sc)) {
        if (nr_dirty && nr_dirty == nr_congested)
            set_bit(ZONE_CONGESTED, &zone->flags);

        if (nr_unqueued_dirty == nr_taken)
            set_bit(ZONE_DIRTY, &zone->flags);
        /* 有一些页是因为回收导致它们在回写，则等待一下设备 */
        if (nr_immediate && current_may_throttle())
            congestion_wait(BLK_RW_ASYNC, HZ/10);
    }

    /* 非kswapd的情况下，如果现在设备回写压力较大 */
    if (!sc->hibernation_mode && !current_is_kswapd() &&
        current_may_throttle())
        /* 等待一下设备 */
        wait_iff_congested(zone, BLK_RW_ASYNC, HZ/10);

    trace_mm_vmscan_lru_shrink_inactive(zone->zone_pgdat->node_id,
        zone_idx(zone),
        nr_scanned, nr_reclaimed,
        sc->priority,
        trace_shrink_flags(file));
    return nr_reclaimed;
}1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
51.
52.
53.
54.
55.
56.
57.
58.
59.
60.
61.
62.
63.
64.
65.
66.
67.
68.
69.
70.
71.
72.
73.
74.
75.
76.
77.
78.
79.
80.
81.
82.
83.
84.
85.
86.
87.
88.
89.
90.
91.
92.
93.
94.
95.
96.
97.
98.
99.
100.
101.
102.
103.
104.
105.
106.
107.
108.
109.
110.
111.
112.
113.
114.
115.
116.
117.
118.
119.
120.
121.
122.
123.
124.
125.
126.
127.
128.
129.
130.
131.
132.
133.
134.
135.
136.
137.
138.
139.
140.
141.
142.
143.
144.
145.
146.
147.
148.
149.
150.
151.
152.
153.
154.
155.
156.
157.
158.
159.
160.
161.
162.
163.
164.
165.
166.
167.
168.
169.
170.
171.
172.
173.
174.
175.
176.
177.
178.
179.
180.
181.
182.

此函数与shrink_inactive_list()函数流程差不多，首先要求当前CPU的所有lru缓存将页放入到lru链表中，然后通过isolate_lru_pages()函数从活动lru链表末尾扫描出符合要求的页，这些页会通过page->lru加入到page_list链表中，然后调用shrink_page_list()对这个page_list链表中的页进行回收处理，之后将page_list链表中剩余的页放回到它们应该放入到链表中。

当把页放回对应的地方后，则将page->_count == 0的页进行释放，这里实际上回收的是在shrink_page_list()中没有进行回收，但是执行完shrink_page_list()后，正巧所有映射了此页的进程都取消了映射，并且此页也不为脏，这就以直接回收了。之后会根据状态标记一些zone的状态。主要进行具体的回收工作函数还是shrink_page_list()：

/* 在page_list中的页都是非活动lru链表的，并且都是同一类型的页(ANON/FILE)
 * 注意page_list中的页还没有被标注进行回收的标志(PG_reclaim)，并且如果为脏页的页(PG_dirty被设置)，那么只有在kswapd调用到此会进行writeback(回写到磁盘)操作
 * 到达这里之前，所有pagevec中的页都放回了lru链表中
 * force_reclaim: 表示是否强制进行回收，强制进行回收则不会判断此页是否应该回收，强制回收的意思是即使页最近被访问过了，也进行回收，除非页被mlock在内存中，或者unmap失败
 * ret_nr_dirty: 脏页数量(包括正在回写和没有回写的脏页)
 * ret_nr_unqueued_dirty: 是脏页但没有进行回写的页
 * ret_nr_congested: 正在进行回写，但是设备正忙
 * ret_nr_writeback: 正在进行回写但不是在回收的页框数量
 * ret_nr_immediate: 正在进行回写的回收页框数量
 */
static unsigned long shrink_page_list(struct list_head *page_list,
                      struct zone *zone,
                      struct scan_control *sc,
                      enum ttu_flags ttu_flags,
                      unsigned long *ret_nr_dirty,
                      unsigned long *ret_nr_unqueued_dirty,
                      unsigned long *ret_nr_congested,
                      unsigned long *ret_nr_writeback,
                      unsigned long *ret_nr_immediate,
                      bool force_reclaim)
{
    /* 初始化两个链表头 */
    LIST_HEAD(ret_pages);
    /* 这个链表保存本次回收就可以立即进行释放的页 */
    LIST_HEAD(free_pages);
    int pgactivate = 0;
    unsigned long nr_unqueued_dirty = 0;
    unsigned long nr_dirty = 0;
    unsigned long nr_congested = 0;
    unsigned long nr_reclaimed = 0;
    unsigned long nr_writeback = 0;
    unsigned long nr_immediate = 0;

    /* 检查是否需要调度，需要则调度 */
    cond_resched();

    /* 将page_list中的页一个一个释放 */
    while (!list_empty(page_list)) {
        struct address_space *mapping;
        struct page *page;
        int may_enter_fs;
        enum page_references references = PAGEREF_RECLAIM_CLEAN;
        bool dirty, writeback;

        /* 检查是否需要调度，需要则调度 */
        cond_resched();

        /* 从page_list末尾拿出一个页 */
        page = lru_to_page(page_list);
        /* 将此页从page_list中删除 */
        list_del(&page->lru);

        /* 尝试对此页上锁，如果无法上锁，说明此页正在被其他路径控制，跳转到keep 
         * 对页上锁后，所有访问此页的进程都会加入到zone->wait_table[hash_ptr(page, zone->wait_table_bits)]
         */
        if (!trylock_page(page))
            goto keep;

        /* 在page_list的页一定都是非活动的 */
        VM_BUG_ON_PAGE(PageActive(page), page);
        /* 页所属的zone也要与传入的zone一致 */
        VM_BUG_ON_PAGE(page_zone(page) != zone, page);

        /* 扫描的页数量++ */
        sc->nr_scanned++;

        /* 如果此页被锁在内存中，则跳转到cull_mlocked */    
        if (unlikely(!page_evictable(page)))
            goto cull_mlocked;

        /* 如果扫描控制结构中标识不允许进行unmap操作，并且此页有被映射到页表中，跳转到keep_locked */
        if (!sc->may_unmap && page_mapped(page))
            goto keep_locked;

        /* Double the slab pressure for mapped and swapcache pages */
        /* 对于处于swapcache中或者有进程映射了的页，对sc->nr_scanned再进行一次++
         * swapcache用于在页换出到swap时，页会先跑到swapcache中，当此页完全写入swap分区后，在没有进程对此页进行访问时，swapcache才会释放掉此页 
         * 这样做是为了让sc->nr_scanned增加得更快?
         */
        if (page_mapped(page) || PageSwapCache(page))
            sc->nr_scanned++;

        /* 本次回收是否允许执行IO操作 */
        may_enter_fs = (sc->gfp_mask & __GFP_FS) ||
            (PageSwapCache(page) && (sc->gfp_mask & __GFP_IO));

        /* 检查是否是脏页还有此页是否正在回写到磁盘 
         * 这里面主要判断页描述符的PG_dirty和PG_writeback两个标志
         * 匿名页当加入swapcache后，就会被标记PG_dirty
         * 如果文件所属文件系统有特定is_dirty_writeback操作，则执行文件系统特定的is_dirty_writeback操作
         */
        page_check_dirty_writeback(page, &dirty, &writeback);
        /* 如果是脏页或者正在回写的页，脏页数量++ */
        if (dirty || writeback)
            nr_dirty++;

        /* 是脏页但并没有正在回写，则增加没有进行回写的脏页计数 */
        if (dirty && !writeback)
            nr_unqueued_dirty++;

        /* 获取此页对应的address_space，如果此页是匿名页，则为NULL */
        mapping = page_mapping(page);
        /* 如果此页映射的文件所在的磁盘设备等待队列中有数据(正在进行IO处理)或者此页已经在进行回写回收 */
        if ((mapping && bdi_write_congested(mapping->backing_dev_info)) ||
            (writeback && PageReclaim(page)))
            /* 可能比较晚才能进行阻塞回写的页的数量 
              * 因为磁盘设备现在繁忙，队列中有太多需要写入的数据
              */
            nr_congested++;

        /* 此页正在进行回写到磁盘，对于正在回写到磁盘的页，是无法进行回收的，除非等待此页回写完成 
         * 此页正在进行回写有两种情况:
         * 1.此页是正常的进行回写(脏太久了)
         * 2.此页是刚不久前进行内存回收时，导致此页进行回写的
         */
        if (PageWriteback(page)) {
            /* Case 1 above */

            /* 下面的判断都是基于此页正在进行回写到磁盘为前提 */

            /* 当前处于kswapd内核进程，并且此页正在进行回收(可能在等待IO)，然后zone也表明了很多页正在进行回写 
             * 说明此页是已经在回写到磁盘，并且也正在进行回收的，本次回收不需要对此页进行回收
             */
            if (current_is_kswapd() &&
                PageReclaim(page) &&
                test_bit(ZONE_WRITEBACK, &zone->flags)) {
                /* 增加nr_immediate计数，此计数说明此页准备就可以回收了 */
                nr_immediate++;
                /* 跳转到keep_locked */
                goto keep_locked;

            /* Case 2 above */
            /* 此页正在进行正常的回写(不是因为要回收此页才进行的回写)
             * 两种情况会进入这里:
             * 1.本次是针对整个zone进行内存回收的
             * 2.本次回收不允许进行IO操作
             * 那么就标记这个页要回收，本次回收不对此页进行回收，当此页回写完成后，会判断这个PG_reclaim标记，如果置位了，把此页放到非活动lru链表末尾
             * 快速回收会进入这种情况
             */
            } else if (global_reclaim(sc) ||
                !PageReclaim(page) || !(sc->gfp_mask & __GFP_IO)) {
                /* 设置此页正在进行回收，因为此页正在进行回写，那设置称为进行回收后，回写完成后此页会被放到非活动lru链表末尾 */
                SetPageReclaim(page);
                /* 增加需要回写计数器 */
                nr_writeback++;

                goto keep_locked;

            /* Case 3 above */
            } else {
                /* 等待此页回写完成，回写完成后，尝试对此页进行回收，应该只有针对某个memcg进行回收时才会进入这 */
                wait_on_page_writeback(page);
            }
        }

        /*
         * 此次回收时非强制进行回收，那要先判断此页需不需要移动到活动lru链表
         * 如果是匿名页，只要最近此页被进程访问过，则将此页移动到活动lru链表头部，否则回收
         * 如果是映射可执行文件的文件页，只要最近被进程访问过，就放到活动lru链表，否则回收
         * 如果是其他的文件页，如果最近被多个进程访问过，移动到活动lru链表，如果只被1个进程访问过，但是PG_referenced置位了，也放入活动lru链表，其他情况回收
         */
        if (!force_reclaim)
            references = page_check_references(page, sc);

        /* 当此次回收时非强制进行回收时 */
        switch (references) {
        /* 将页放到活动lru链表中 */
        case PAGEREF_ACTIVATE:
            goto activate_locked;
        /* 页继续保存在非活动lru链表中 */
        case PAGEREF_KEEP:
            goto keep_locked;

        /* 这两个在下面的代码都会尝试回收此页 
         * 注意页所属的vma标记了VM_LOCKED时也会是PAGEREF_RECLAIM，因为后面会要把此页放到lru_unevictable_page链表
         */
        case PAGEREF_RECLAIM:
        case PAGEREF_RECLAIM_CLEAN:
            ; /* try to reclaim the page below */
        }

        /* page为匿名页，但是又不处于swapcache中，这里会尝试将其加入到swapcache中，这个swapcache作为swap缓冲区 
         * 当页被换出或换入时，会先加入到swapcache，当完全换出或者完全换入时，才会从swapcache中移除
         * 有了此swapcache，当一个页进行换出时，一个进程访问此页，可以直接从swapcache中获取此页的映射，然后swapcache终止此页的换出操作，这样就不用等页要完全换出后，再重新换回来
         */
        if (PageAnon(page) && !PageSwapCache(page)) {
            /* 如果本次回收禁止io操作，则跳转到keep_locked，让此匿名页继续在非活动lru链表中 */
            if (!(sc->gfp_mask & __GFP_IO))
                goto keep_locked;
            /* 将页page加入到swap_cache，然后这个页被视为文件页，起始就是将页描述符信息保存到以swap页槽偏移量为索引的结点
              * 设置页描述符的private = swap页槽偏移量生成的页表项swp_entry_t，因为后面会设置所有映射了此页的页表项为此swp_entry_t
              * 设置页的PG_swapcache标志，表明此页在swapcache中，正在被换出
               * 标记页page为脏页(PG_dirty)，后面就会被换出
              */
              /* 执行成功后，页属于swapcache，并且此页的page->_count会++，但是由于引用此页的进程页表没有设置，进程还是可以正常访问这个页 */
            if (!add_to_swap(page, page_list))
                /* 失败，将此页加入到活动lru链表中 */
                goto activate_locked;
            /* 设置可能会用到文件系统相关的操作 */
            may_enter_fs = 1;

            /* Adding to swap updated mapping */
            /* 获取此匿名页所在的swapcache的address_space，这个是根据page->private中保存的swp_entry_t获得 */
            mapping = page_mapping(page);
        }

        /* 这里是要对所有映射了此page的页表进行设置
         * 匿名页会把对应的页表项设置为之前获取的swp_entry_t
         */
        if (page_mapped(page) && mapping) {
            /* 对所有映射了此页的进程的页表进行此页的unmap操作
             * ttu_flags基本都有TTU_UNMAP标志
             * 如果是匿名页，那么page->private中是一个带有swap页槽偏移量的swp_entry_t，此后这个swp_entry_t可以转为页表项
             * 执行完此后，匿名页在swapcache中，而对于引用了此页的进程而言，此页已经在swap中
             * 但是当此匿名页还没有完全写到swap中时，如果此时有进程访问此页，会将此页映射到此进程页表中，并取消此页放入swap中的操作，放回匿名页的lru链表(在缺页中断中完成)
             * 而对于文件页，只需要清空映射了此页的进程页表的页表项，不需要设置新的页表项
             * 每一个进程unmap此页，此页的page->_count--
             * 如果反向映射过程中page->_count == 0，则释放此页
             */
            switch (try_to_unmap(page, ttu_flags)) {
            case SWAP_FAIL:
                goto activate_locked;
            case SWAP_AGAIN:
                goto keep_locked;
            case SWAP_MLOCK:
                goto cull_mlocked;
            case SWAP_SUCCESS:
                ; /* try to free the page below */
            }
        }

        /* 如果页为脏页，有两种页
         * 一种是当匿名页加入到swapcache中时，就被标记为了脏页
         * 一种是脏的文件页
         */
        if (PageDirty(page)) {
            /* 只有kswapd内核线程能够进行文件页的回写操作(kswapd中不会造成栈溢出?)，但是只有当zone中有很多脏页时，kswapd也才能进行脏文件页的回写
             * 此标记说明zone的脏页很多，在回收时隔离出来的页都是没有进行回写的脏页时设置
             * 也就是此zone脏页不够多，kswapd不用进行回写操作
             * 当短时间内多次对此zone执行内存回收后，这个ZONE_DIRTY就会被设置，这样做的理由是: 优先回收匿名页和干净的文件页，说不定回收完这些zone中空闲内存就足够了，不需要再进行内存回收了
             * 而对于匿名页，无论是否是kswapd都可以进行回写
             */
            if (page_is_file_cache(page) &&
                    (!current_is_kswapd() ||
                     !test_bit(ZONE_DIRTY, &zone->flags))) {
                /* 增加优先回收页的数量 */
                inc_zone_page_state(page, NR_VMSCAN_IMMEDIATE);
                /* 设置此页需要回收，这样当此页回写完成后，就会被放入到非活动lru链表尾部 
                 * 不过可惜这里只能等kswapd内核线程对此页进行回写，要么就等系统到期后自动将此页进行回写，非kswapd线程都不能对文件页进行回写
                 */
                SetPageReclaim(page);

                /* 让页移动到非活动lru链表头部，如上所说，当回写完成后，页会被移动到非活动lru链表尾部，而内存回收是从非活动lru链表尾部拿页出来回收的 */
                goto keep_locked;
            }

            /* 当zone没有标记ZONE_DIRTY时，kswapd内核线程则会执行到这里 */
            /* 当page_check_references()获取页的状态是PAGEREF_RECLAIM_CLEAN，则跳到keep_locked
             * 页最近没被进程访问过，但此页的PG_referenced被置位
             */
            if (references == PAGEREF_RECLAIM_CLEAN)
                goto keep_locked;
            /* 回收不允许执行文件系统相关操作，则让页移动到非活动lru链表头部 */
            if (!may_enter_fs)
                goto keep_locked;
            /* 回收不允许进行回写，则让页移动到非活动lru链表头部 */
            if (!sc->may_writepage)
                goto keep_locked;

            /* Page is dirty, try to write it out here */
            /* 将页进行回写到磁盘，这里只是将页加入到块层，调用结束并不是代表此页已经回写完成
             * 主要调用page->mapping->a_ops->writepage进行回写，对于匿名页，也是swapcache的address_space->a_ops->writepage
             * 页被加入到块层回写队列后，会置位页的PG_writeback，回写完成后清除PG_writeback位，所以在同步模式回写下，结束后PG_writeback位是0的，而异步模式下，PG_writeback很可能为1
             * 此函数中会清除页的PG_dirty标志
             * 会标记页的PG_reclaim
             * 成功将页加入到块层后，页的PG_lock位会清空
             * 也就是在一个页成功进入到回收导致的回写过程中，它的PG_writeback和PG_reclaim标志会置位，而它的PG_dirty和PG_lock标志会清除
             * 而此页成功回写后，它的PG_writeback和PG_reclaim位都会被清除
             */
            switch (pageout(page, mapping, sc)) {
            case PAGE_KEEP:
                /* 页会被移动到非活动lru链表头部 */
                goto keep_locked;
            case PAGE_ACTIVATE:
                /* 页会被移动到活动lru链表 */
                goto activate_locked;
            case PAGE_SUCCESS:
                /* 到这里，页的锁已经被释放，也就是PG_lock被清空 
                 * 对于同步回写(一些特殊文件系统只支持同步回写)，这里的PG_writeback、PG_reclaim、PG_dirty、PG_lock标志都是清0的
                 * 对于异步回写，PG_dirty、PG_lock标志都是为0，PG_writeback、PG_reclaim可能为1可能为0(回写完成为0，否则为1)
                 */

                /* 如果PG_writeback被置位，说明此页正在进行回写，这种情况是异步才会发生 */
                if (PageWriteback(page))
                    goto keep;
                
                /* 此页为脏页，这种情况发生在此页最近又被写入了，让其保持在非活动lru链表中 
                 * 还有一种情况，就是匿名页加入到swapcache前，已经没有进程映射此匿名页了，而加入swapcache时不会判断
                 * 但是当对此匿名页进行回写时，会判断此页加入swapcache前是否有进程映射了，如果没有，此页可以直接释放，不需要写入磁盘
                 * 所以在此匿名页回写过程中，就会将此页从swap分区的address_space中的基树拿出来，然后标记为脏页，到这里就会进行判断脏页，之后会释放掉此页
                 */
                if (PageDirty(page))
                    goto keep;
                /* 尝试上锁，因为在pageout中会释放page的锁，主要是PG_lock标志 */
                if (!trylock_page(page))
                    goto keep;
                if (PageDirty(page) || PageWriteback(page))
                    goto keep_locked;
                /* 获取page->mapping */
                mapping = page_mapping(page);

            /* 这个页不是脏页，不需要回写，这种情况只发生在文件页，匿名页当加入到swapcache中时就被设置为脏页 */
            case PAGE_CLEAN:
                ; /* try to free the page below */
            }
        }

        /* 这里的情况只有页已经完成回写后才会到达这里，比如同步回写时(pageout在页回写完成后才返回)，异步回写时，在运行到此之前已经把页回写到磁盘
         * 没有完成回写的页不会到这里，在pageout()后就跳到keep了
         */
        
        /* 通过页描述符的PAGE_FLAGS_PRIVATE标记判断是否有buffer_head，这个只有文件页有
         * 这里不会通过page->private判断，原因是，当匿名页加入到swapcache时，也会使用page->private，而不会标记PAGE_FLAGS_PRIVATE
         * 只有文件页会使用这个PAGE_FLAGS_PRIVATE，这个标记说明此文件页的page->private指向struct buffer_head链表头
         */
        if (page_has_private(page)) {
            /* 因为页已经回写完成或者是干净不需要回写的页，释放page->private指向struct buffer_head链表，释放后page->private = NULL 
             * 释放时必须要保证此页的PG_writeback位为0，也就是此页已经回写到磁盘中了
             */
            if (!try_to_release_page(page, sc->gfp_mask))
                /* 释放失败，把此页移动到活动lru链表 */
                goto activate_locked;

            /* 一些特殊的页的mapping为空，比如一些日志的缓冲区，对于这些页如果引用计数为1则进行处理 */
            if (!mapping && page_count(page) == 1) {
                /* 对此页解锁，清除PG_lock */
                unlock_page(page);
                /* 对page->_count--，并判断是否为0，如果为0则释放掉此页 */
                if (put_page_testzero(page))
                    goto free_it;
                else {
                    /* 这里不太明白，大概意思是这些页马上就会在其他地方被释放了，所以算作回收页 */
                    
                    nr_reclaimed++;
                    continue;
                }
            }
        }

        /* 
         * 经过上面的步骤，在没有进程再对此页进行访问的前提下，page->_count应该为2
         * 表示只有将此页隔离出lru的链表和加入address_space的基树中对此页进行了引用，已经没有其他地方对此页进行引用，
         * 然后将此页从address_space的基数中移除，然后page->_count - 2，这个页现在就只剩等待着被释放掉了
         * 如果是匿名页，则是对应的swapcache的address_space的基树
         * 如果是文件页，则是对应文件的address_space的基树
         * 当page->_count为2时，才会将此页从address_space的基数中移除，然后再page->_count - 2
         * 相反，如果此page->_count不为2，说明unmap后又有进程访问了此页，就不对此页进行释放了
         * 同时，这里对于脏页也不能够进行释放，想象一下，如果一个进程访问了此页，写了数据，又unmap此页，那么此页的page->_count为2，同样也可以释放掉，但是写入的数据就丢失了
         * 成功返回1，失败返回0
         */
        if (!mapping || !__remove_mapping(mapping, page, true))
            goto keep_locked;

        /* 释放page锁 */
        __clear_page_locked(page);
free_it:
        /* page->_count为0才会到这 */
        
        /* 此页可以马上回收，会把它加入到free_pages链表
         * 到这里的页有三种情况，本次进行同步回写的页，干净的不需要回写的页，之前异步回收时完成异步回写的页
         * 之前回收进行异步回写的页，不会立即释放，因为上次回收时，对这些页进行的工作有: 
         * 匿名页: 加入swapcache，反向映射修改了映射了此页的进程页表项，将此匿名页回写到磁盘，将此页保存到非活动匿名页lru链表尾部
         * 文件页: 反向映射修改了映射了此页的进程页表项，将此文件页回写到磁盘，将此页保存到非活动文件页lru链表尾部
         * 也就是异步情况这两种页都没有进行实际的回收，而在这些页回写完成后，再进行回收时，这两种页的流程都会到这里进行回收
         * 也就是本次能够真正回收到的页，可能是之前进行回收时已经处理得差不多并回写完成的页
         */
        
        /* 回收页数量++ */
        nr_reclaimed++;

        /* 加入到free_pages链表 */
        list_add(&page->lru, &free_pages);
        /* 继续遍历页 */
        continue;

cull_mlocked:
        /* 当前页被mlock所在内存中的情况 */

        /* 此页为匿名页并且已经放入了swapcache中了 */
        if (PageSwapCache(page))
            /* 从swapcache中释放本页在基树的结点，会page->_count-- */
            try_to_free_swap(page);
        
        unlock_page(page);
        /* 把此页放回到lru链表中，因为此页已经被隔离出来了
         * 加入可回收lru链表后page->_count++，但同时也会释放隔离的page->_count--
         * 加入unevictablelru不会进行page->_count++
         */
        putback_lru_page(page);
        continue;

activate_locked:
        /* Not a candidate for swapping, so reclaim swap space. */
        /* 这种是持有页锁(PG_lock)，并且需要把页移动到活动lru链表中的情况 */

        /* 如果此页为匿名页并且放入了swapcache中，并且swap使用率已经超过了50% */
        if (PageSwapCache(page) && vm_swap_full())
            /* 将此页从swapcache的基树中拿出来 */
            try_to_free_swap(page);
        VM_BUG_ON_PAGE(PageActive(page), page)
        /* 设置此页为活动页 */;
        SetPageActive(page);
        /* 需要放回到活动lru链表的页数量 */
        pgactivate++;
keep_locked:
        /* 希望页保持在原来的lru链表中，并且持有页锁的情况 */

        /* 释放页锁(PG_lock) */
        unlock_page(page);
keep:
        /* 希望页保持在原来的lru链表中的情况 */

        /* 把页加入到ret_pages链表中 */
        list_add(&page->lru, &ret_pages);
        VM_BUG_ON_PAGE(PageLRU(page) || PageUnevictable(page), page);
    }

    mem_cgroup_uncharge_list(&free_pages);
    /* 将free_pages中的页释放 */
    free_hot_cold_page_list(&free_pages, true);

    /* 将ret_pages链表加入到page_list中 */
    list_splice(&ret_pages, page_list);
    count_vm_events(PGACTIVATE, pgactivate);

    *ret_nr_dirty += nr_dirty;
    *ret_nr_congested += nr_congested;
    *ret_nr_unqueued_dirty += nr_unqueued_dirty;
    *ret_nr_writeback += nr_writeback;
    *ret_nr_immediate += nr_immediate;
    return nr_reclaimed;
}1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
51.
52.
53.
54.
55.
56.
57.
58.
59.
60.
61.
62.
63.
64.
65.
66.
67.
68.
69.
70.
71.
72.
73.
74.
75.
76.
77.
78.
79.
80.
81.
82.
83.
84.
85.
86.
87.
88.
89.
90.
91.
92.
93.
94.
95.
96.
97.
98.
99.
100.
101.
102.
103.
104.
105.
106.
107.
108.
109.
110.
111.
112.
113.
114.
115.
116.
117.
118.
119.
120.
121.
122.
123.
124.
125.
126.
127.
128.
129.
130.
131.
132.
133.
134.
135.
136.
137.
138.
139.
140.
141.
142.
143.
144.
145.
146.
147.
148.
149.
150.
151.
152.
153.
154.
155.
156.
157.
158.
159.
160.
161.
162.
163.
164.
165.
166.
167.
168.
169.
170.
171.
172.
173.
174.
175.
176.
177.
178.
179.
180.
181.
182.
183.
184.
185.
186.
187.
188.
189.
190.
191.
192.
193.
194.
195.
196.
197.
198.
199.
200.
201.
202.
203.
204.
205.
206.
207.
208.
209.
210.
211.
212.
213.
214.
215.
216.
217.
218.
219.
220.
221.
222.
223.
224.
225.
226.
227.
228.
229.
230.
231.
232.
233.
234.
235.
236.
237.
238.
239.
240.
241.
242.
243.
244.
245.
246.
247.
248.
249.
250.
251.
252.
253.
254.
255.
256.
257.
258.
259.
260.
261.
262.
263.
264.
265.
266.
267.
268.
269.
270.
271.
272.
273.
274.
275.
276.
277.
278.
279.
280.
281.
282.
283.
284.
285.
286.
287.
288.
289.
290.
291.
292.
293.
294.
295.
296.
297.
298.
299.
300.
301.
302.
303.
304.
305.
306.
307.
308.
309.
310.
311.
312.
313.
314.
315.
316.
317.
318.
319.
320.
321.
322.
323.
324.
325.
326.
327.
328.
329.
330.
331.
332.
333.
334.
335.
336.
337.
338.
339.
340.
341.
342.
343.
344.
345.
346.
347.
348.
349.
350.
351.
352.
353.
354.
355.
356.
357.
358.
359.
360.
361.
362.
363.
364.
365.
366.
367.
368.
369.
370.
371.
372.
373.
374.
375.
376.
377.
378.
379.
380.
381.
382.
383.
384.
385.
386.
387.
388.
389.
390.
391.
392.
393.
394.
395.
396.
397.
398.
399.
400.
401.
402.
403.
404.
405.
406.
407.
408.
409.
410.
411.
412.
413.
414.
415.
416.
417.
418.
419.
420.
421.
422.
423.
424.
425.
426.
427.
428.
429.
430.
431.
432.
433.
434.
435.
436.
437.
438.
439.
440.
441.
442.

shrink_page_list()，它的工作就是对page_list链表中的每个页尝试进行回收操作了，但是进行回收操作，并不等于此页就可以立即进行回收，因为如果为脏页的话，回写到磁盘的操作是异步的，而这些页将在回写完成后进行回收，具体怎么做的，我们慢慢道来。首先，在shrink_page_list()中会遍历page_list链表中的每一个页，然后对每个遍历到的页都进行处理，先总结一下这个shrink_page_list()对每个遍历到的页主要做哪几件事情：

检查此页是否正在回写(通过页描述符的PG_writeback标志)，然后做相应的处理
检查此页最近是否有被访问过(非文件页通过页表项的Accessed判断，文件页通过页描述符的PG_referenced和页表项的Accessed判断)，有则进行相应处理(此页就不一定被回收)
如果是非文件页，检查此页是否加入到了swap cache(置位PG_swapcache)，没有则将此页加入到swap cache(通过PG_swapcache判断)，并且标记非文件页为脏页(重要，标记PG_dirty)以及page->_count++，会为此非文件页分配一个swap类型的页表项，保存到page->private中
如果有进程映射了此页，则进行unmap操作(是否执行unmap操作与sc->may_unmap有关)，如果是非文件页，那么映射了此非文件页的页表项被设置为之前分配的swap类型的页表项，如果是文件页，则清空页表项
如果页为脏页，则对此页进行异步回写(是否执行回写操作与sc->may_writepage有关)，一些特殊的文件系统可能进行同步回写(比如ramdisk)，然后设置此页的PG_reclaim。这里需要注意，只有kswap能够对文件页进行回写
如果此页是文件页，并且包含有buffer_heads(会以链表的形式保存在page->private中)，则释放其buffer_heads链表，注意这个buffer_heads是文件页特有的，因为文件离散地保存在磁盘中，而swap分区是连续的，所以非文件页并不需要这个buffer_heads。
将page->_count == 2和page->_count == 0的干净页进行回收，并将它们从swap cache 或者 page cache中移除
除了回收的页，其余的页都放回到对应的lru链表中。

先讨论第一件事情，就是检查这个页是否在进行回写操作，这里要先说说块层的异步回写的结束后的处理函数end_buffer_async_write()，这个函数将一个页回写完成后会检查页的PG_reclaim标志，如果置位了则将此页移动到非活动lru链表末尾，因为内存回收扫描是从lru链表的末尾进行的，在下次进行内存回收扫描时，会优先扫描到此页，也可以对此页进行优先释放回收。

那么，现在在shrink_page_list()中，如果遍历到的页在进行回写操作(通过页的PG_writeback位判断)，那么导致此页进行回写的情况有两种：页脏太久了，系统自动将其回写(PG_writeback置位，而PG_reclaim没有置位)；页最近被内存回收处理过，是内存回收要求它进行回写(PG_writeback和PG_reclaim都置位了)。对于第一种情况，则将此页的PG_reclaim置位，这样此页在回写完成后，就会被放到非活动lru链表末尾，这样在下次内存回收时，此页就很大可能被作为一个干净页去释放回收。对于第二种可能，这个页本来就是进行内存释放时主动要求其回写的，那么此页的PG_writeback和PG_reclaim都在之前处理此页的内存回收时置位了，这里就不做什么了。

判断完遍历到的页是否正在进行回写后，还需要判断此页最近是否被访问过，处理如下：

（1）如果扫描的是非活动文件页lru链表，本次回收跳过的页有：

此文件页最近被多个进程访问(多个映射此页的进程页表项Accessed被置位)，则将页移动到活动文件页lru链表头部。
此页的PG_referenced被置位，则将页移动到活动文件页lru链表头部。
对于最近被访问过的代码段文件页，移动到活动文件页lru链表头部。

（2）如果扫描的是非活动匿名页lru链表，本次回收跳过的页有：

对于最近访问过的页(一个或多个映射了此页的进程页表项的Accessed被置位)，将页移动到活动匿名页lru链表尾部中。
对于正在回写的页，将页移动到非活动匿名页lru链表头部，并标记这些页的PG_reclaim。

（3）除了以上这些页，其他页都可以顺利通过检查，之前的工作相当于判断此页能否进行回收，现在开始的工作就是为此页的回收做准备了，总的来说，就是三件事：

非文件页加入到swap cache
对页进行unmap操作
调用page->mapping->a_ops->writepage进行异步回写

当一个非文件页加入swap cache时，主要对此文件做几件事，首先，分配一个swap类型的页表项，将所有映射了此页的进程页表项设置为这个swap类型的页表项；其次，置位此页的PG_dirty，标记此页是一个脏页，这样后面就会通过判断这个进行异步回写了；最后，将此页的mapping指向swap分区的address_space，这样在进行异步回写时，就能够通过swap分区的address_space->a_ops->writepage函数将此页异步回写到swap分区中。对于文件页来说，则没有这一步加入到swap cache中，因为每个文件都有自己的address_space，一个新的文件页就已经有对应文件的address_space了。

之后进行unmap操作，对于非文件页，这个的工作就是将映射了此非文件页的页表项设置为之前分配的swap类型的页表项，而对于文件页来说，则清空映射了此文件页的进程页表项。

然后，就调用页描述符中的page->mapping->a_ops->writepage将页进行异步回写，这里需要注意，只对脏页进行异步回写，这就是为什么当非文件页加入到swap cache后，要设置为脏页，这里就会将它回写到磁盘，而对于文件页，只有数据与磁盘中不一致时，才需要回写。并且这里会对脏页设置PG_reclaim标志，而干净页则不用。

好了，这几步做完了，可以将此页进行回收了吧，可惜这时候只能对不用进行回写的干净页进行回收，因为回写是异步进行的，这些正在进行回写的页，会被放到非活动lru链表头部，这里就与前面说的相呼应了，当回写完成后，通过判断PG_reclaim标志，会将页移动到非活动lru链表末尾，这样在下次进行内存回收时，这些页就更优先进行回收了。

假设现在内存回收扫描到了这个回写完成的页，如果此页是文件页，那么它还必定会有一个buffer_heads链表需要进行释放，这个buffer_heads用于描述此页需要回写到磁盘的位置。当文件页回写完后，如果此文件页又被内存回收扫描到了，准备对它回收，那么就会将此文件页的buffer_heads进行释放。buffer_heads都保存页描述符page->private中。

之后，如果回收的是文件页，那么还必须将此页从所属文件的page cache中移除，如果回收的是非文件页页，也必须将此页从所属swap分区的swap cache中移除。

到这里，此页已经可以进行回收了。

下面我们默认此页能够回收，忽略回收检查，并且默认没有进程在此期间访问页，将页分为干净文件页，脏文件页，非文件页描述一下回收过程(非文件页只要加入到swap cache中就会被设置为脏页)：

图片

可以看到，对于干净文件页，由于文件页不加入swapcache，只需要进行一个unmap操作，就可以直接进行回收了，这种页回收效率是最高的。对于脏文件页：

图片

可以看到对于脏文件页，待其回写完成后，内核进行一次内存回收时，如果扫描到此页，只需要直接将其释放就可以了。注意：只有kswapd内核线程能够对脏文件页进行回写操作，并且回写完成后并不会主动要求内核进行一次内存回收，也有可能回写完成后，zone的内存足够了，就不进行内存回收了。再看看非文件页的回收流程：

图片

其实很简单，对于脏页，在回写之后的下次内存回收时，就可以将其回收，而对于干净的页，在本次内存回收时，就可以将其回收。而当非文件页加入swapcache后，就会被设置为脏页(PG_dirty置位)。

其实可以总结，非文件页相对于文件页来说，在内存回收处理过程中有以下区别：

一般回收的非文件页在非活动匿名页lru链表中，而回收的文件页在非活动文件页lru链表中。
非文件页回写前必须要加入swapcache，并会生成一个以页槽号为偏移量的swap类型的页表项；而文件页不会加入swapcache，并且没有swap类型的页表项
unmap时，映射了非文件页的进程页表项会被设置为swao类型的页表项，而映射了文件页的进程页表项则直接清空
非文件页在有进程映射了的情况下，一定要进行回写后才能回收；而文件页即使没有进程映射的情况下，只要是脏页，回收时都要回写
非文件页没有buffer_heads，不需要对buffer_heads进行回收，而文件页回写完后进行需要进行buffer_heads的回收

现在再说说在回写过程中，又有进程映射了此页怎么办，这里我们结合page->_count来说，之前有说过，当有模块引用或者进程映射了此页的时候，此页的page->_count就会++，这里我们假设一个场景，有10个进程映射了一个非文件页，没有其他模块引用此非文件页，那么此页的page->_count就为10。

然后此页在非活动匿名页lru链表中被内存回收扫描到，内核打算对此页进行回收，第一件做的事情，将此页从lru链表隔离出来，这里page->_count++(就等于11了)。第二件事，将此页加入到swap cache中，page->_count++(现在等于12了)。第三件事，对此页进行unmap，由于有10个进程映射了此页，unmap后，此页的page->_count -= 10，现在page->_count就剩2了，如果此页是干净页，那么如之前说的，回收时判断page->_count == 2的可以进行回收。

如果此页是脏页，那么就回写，然后将此页放回到非活动匿名页lru链表，这时page->_count会减1(这时候就为1了，这里为1是因为swapcache在引用此页)。之后回写完成再被扫描到时，一样会进行隔离，那么page->_count++(现在为2了)，最后一样可以通过page->_count == 2判断此页能够释放。这样说明，如果在回写过程中，有进程又映射了此页，因为映射此页那么page->_count就会增加，在回写完成后的回收时，此page->_count就不可能变为0了，更何况由于有进程映射了此页，说明此进程最近访问了此页，此页还会被移动到活动匿名页lru链表中。而对于文件页，即使没有进程映射它，它的page->_count就为1，因为它自出身一来，就被对应文件的page cache引用了。并且因为文件页不需要加入到swap cache，实际上在内存回收过程中，当没有进程映射此文件页时，它的page->_count一样为2。

5.4内存回收系统性能的影响

(1)内存回收与系统响应速度

内存回收机制对系统响应速度的影响可谓立竿见影。当内存回收不及时，就如同交通拥堵时没有交警指挥，系统会陷入混乱。例如，在一个多任务处理的场景中，同时运行着多个进程，如办公软件、浏览器、数据库服务等。随着时间的推移，一些进程产生的临时数据占用了大量内存，而这些数据在当前任务完成后本应被回收。然而，由于内存回收不及时，这些占用内存的临时数据得不到释放，新的进程在申请内存时就会遇到阻碍。

想象一下，当你在浏览器中打开多个网页，同时还在运行办公软件进行文档编辑，突然想要启动一个大型数据库查询任务。此时，如果内存回收不及时，数据库进程可能因为无法获得足够的内存而迟迟无法执行查询操作，导致你在等待查询结果时，浏览器和办公软件也变得卡顿，响应迟缓。这是因为系统在努力协调有限的内存资源，各个进程都在竞争内存，导致整体的系统响应速度大幅下降。

(2)内存回收与系统稳定性

内存持续高占用且无法回收，就像一座随时可能爆发的火山，对系统稳定性构成巨大威胁。在服务器环境中，这一问题的影响尤为严重。例如，一个长时间运行的 Web 服务器，每天要处理大量的用户请求。随着用户访问量的不断增加，服务器内存中的数据也越来越多。如果内存回收机制出现故障，无法及时回收不再使用的内存，内存占用率会持续攀升。

当内存占用达到一定程度，服务器可能会出现各种异常情况。首先，进程之间可能会因为争夺内存资源而发生冲突，导致部分进程崩溃。其次，系统可能会频繁出现内存分配失败的错误，使得新的服务请求无法得到处理。最严重的情况是，整个服务器可能会因为内存耗尽而死机，无法正常响应任何用户请求。这不仅会影响用户体验，还可能给企业带来巨大的经济损失，如电商平台在促销活动期间，若服务器因内存问题崩溃，可能会导致大量订单丢失，品牌声誉受损。

六、如何优化内向回收机制

6.1合理设置内存水位标记

在 Linux 系统内存管理的精密体系中，内存水位标记起着关键作用，而 min_free_kbytes 就是调整内存水位标记的一把 “金钥匙”。min_free_kbytes 代表着系统中每个内存管理区（zone）需要保留的最少空闲内存数量，这个数值犹如系统内存的一道 “安全底线”，对内存回收的触发时机和力度有着深远影响。

在系统初始化时，min_free_kbytes 的数值会依据系统内存总量以及各内存管理区的页框数量，通过一套复杂的算法精准计算得出。我们可以通过修改 /proc/sys/vm/min_free_kbytes 文件中的数值，轻松实现对它的调整。举个例子，当我们将 min_free_kbytes 的值调高时，就好比提高了水位标记中的最低水位。这会使得系统在内存分配时变得更加 “保守”，一旦空闲内存量接近这个提高后的最低水位，内存回收机制就会被迅速触发，就像提前拉响了警报，kswapd 会更早地开始回收内存。这样做的好处是，能够有效避免内存过度使用，减少直接内存回收的发生频率，让系统在面对内存压力时更加从容，维持系统的稳定性和性能。

然而，任何调整都需要谨慎权衡。如果 min_free_kbytes 设置得过高，虽然能在一定程度上避免内存紧张，但也会导致系统中可用于常规分配的内存减少，就像预留了过多的 “战略储备”，使得其他正常的内存需求无法得到充分满足。比如，在一个同时运行多个大型应用程序的服务器上，如果 min_free_kbytes 设置过高，可能会导致新启动的应用程序在申请内存时遇到困难，出现运行缓慢甚至无法启动的情况。

相反，若 min_free_kbytes 设置得过低，系统就像一个缺乏警惕的守卫，内存回收机制启动过晚。当内存真正紧张时，可能就不得不频繁依赖直接内存回收这种 “紧急措施” ，这会严重影响系统性能，就像在危机时刻才匆忙应对，导致整个系统陷入混乱，出现卡顿、响应迟缓等问题。所以，在设置 min_free_kbytes 时，我们需要根据系统的实际内存使用情况、运行的应用程序特点等因素，进行细致的评估和合理的调整，找到那个既能保障内存稳定供应，又能充分发挥系统性能的平衡点。

6.2优化 swap 参数

在 Linux 内存管理的大舞台上，swap 参数中的 swappiness 就像一位掌控内存交换节奏的 “指挥家”，它的取值直接决定了系统对交换空间（swap space）的依赖程度，进而深刻影响着内存回收策略。swappiness 的取值范围在 0 到 100 之间，默认值通常为 60 ，这个数值就像是一个 “开关”，调节着系统将内存页面换出到交换空间的积极性。

当 swappiness 的值较低时，比如设置为 10 ，系统就如同一个偏好 “现用现取” 的使用者，更加倾向于优先使用物理内存。这意味着只有当物理内存几乎被耗尽，实在没有其他可用内存时，系统才会极不情愿地将内存页面换出到交换空间。在这种情况下，内存回收主要集中在对物理内存中不常用页面的清理，因为系统尽量避免使用交换空间，所以交换空间的使用频率会显著降低。对于那些对响应速度要求极高的应用场景，如游戏服务器、实时数据分析系统等，较低的 swappiness 设置可以减少磁盘 I/O 操作，因为从磁盘交换数据比从物理内存读取数据要慢得多，从而大大提高系统的响应速度和整体性能。

相反，当 swappiness 的值较高，例如设置为 90 时，系统就像一个 “未雨绸缪” 的管理者，非常积极地将内存中暂时不用的页面换出到交换空间。这样做的好处是可以快速释放物理内存，让物理内存始终保持相对充足的状态，为新的内存分配请求提供更多的空间。然而，频繁地进行内存与交换空间的数据交换，会导致磁盘 I/O 操作大幅增加，因为每次页面换出和换入都需要与磁盘进行数据传输。

这对于磁盘性能较差的系统来说，无疑是雪上加霜，会严重影响系统的整体性能，导致系统运行变得迟缓。在一些对内存容量需求较大，但对响应速度要求相对不那么高的应用场景中，如大型文件服务器、离线数据处理系统等，适当提高 swappiness 的值，可以更好地利用系统内存资源，避免因物理内存不足而导致的进程崩溃等问题。所以，我们需要根据系统的实际应用场景和性能需求，灵活调整 swappiness 的值，以实现内存回收策略的优化，让系统在不同的工作负载下都能保持良好的运行状态。